Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changeset Comment Field Locks Up Browser Tab #4611

Closed
IcyMidnight opened this issue Dec 13, 2017 · 10 comments
Closed

Changeset Comment Field Locks Up Browser Tab #4611

IcyMidnight opened this issue Dec 13, 2017 · 10 comments
Labels
performance Optimizing for speed and efficiency

Comments

@IcyMidnight
Copy link

IcyMidnight commented Dec 13, 2017

When using the iD editor on www.openstreetmap.org in Chrome (Version 62.0.3202.94 (Official Build) (64-bit)), typing in the changeset comment field causes the tab to lock up.

It sort of looks like iD is trying to autocomplete the comment from some history and does a lot of work on each key press. In one instance, I blindly typed a sentence or so of a comment and then had to wait 5+ minutes for the tab to revive and become responsive. Most of what I typed did finally show up.

Things seem to get worse with larger changesets.

@bhousel bhousel added the performance Optimizing for speed and efficiency label Dec 13, 2017
@bhousel
Copy link
Member

bhousel commented Dec 17, 2017

This is #4587 but I thought was fixed server-side. @IcyMidnight is this still an issue?
Can you follow the steps on #4587 to check whether the slowness is in something iD is doing vs. a slow response from the OSM API? Thanks!

@boothym
Copy link
Contributor

boothym commented Dec 18, 2017

Unfortunately I get the same thing, and I've only noticed it in larger changesets. Will try to figure out how many changes it takes to become really slow.

I looked at the response time for the XHR request but it's ~400ms in total.

@IcyMidnight
Copy link
Author

Still seeing it today. It's not crazy, but I have a 35 change changeset where typing is already noticeable delayed.

@boothym
Copy link
Contributor

boothym commented Dec 21, 2017

Same as above, entering text in the changeset comment box gets noticeably slower even at around 30 changes. And when I had over 150 changes, entering text in a normal text field was slower as well.

@bborkmiller
Copy link

This might sound crazy, but my seat-of-the-pants impression is that the changeset comment slowness has more to do with how much panning I've done in the map than how many changes I've made. A relatively small changeset that covers a lot of ground, like this one, can slow down the comment field.

@bhousel
Copy link
Member

bhousel commented Jan 23, 2018

My guess is that with every keystroke it rebuilds the entire sidebar, and the more changes you've made, the longer it takes to build the changeset summary. D3 does funny stuff like that if we're not careful with our data joins and enter/update/exit selections.

@talllguy
Copy link

talllguy commented Feb 2, 2018

My workaround is to type the entire comment without seeing any of it show up, then change to another tab and write an email or something, then come back to find my comment has appeared. 😆

@bhousel
Copy link
Member

bhousel commented Feb 2, 2018

Yeah, I feel bad I didn't get this fixed in time for today's 2.6.1 patch release. Maybe next week 😄

@homersimpsons
Copy link
Contributor

@tallguy or maybe you can write your comment elsewhere and then copy paste?

@bhousel
Copy link
Member

bhousel commented Feb 5, 2018

This is much better now. #2743 involved speeding up the coreDifference code. The commit screen was recalculating all of the edits performed by the user with every keypress. That calculation used to take several seconds, now takes around 2 milliseconds. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Optimizing for speed and efficiency
Projects
None yet
Development

No branches or pull requests

6 participants