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

Should not try to scroll cursor into view while hidden #1236

Closed
njx opened this issue Feb 12, 2013 · 4 comments
Closed

Should not try to scroll cursor into view while hidden #1236

njx opened this issue Feb 12, 2013 · 4 comments

Comments

@njx
Copy link

njx commented Feb 12, 2013

In endOperation(), if the selection has changed, we call calculateScrollPos() to figure out how to scroll the selection into view. However, if the editor is hidden, calculateScrollPos() returns a bogus value, because display.scroller.clientHeight is 0. This value can end up getting saved off in doc.scrollTop, which then messes up future refresh() operations that try to use the cached value. (In our case, where we have a small hidden inline editor, the bad scroll value actually causes the content to become invisible, because it essentially scrolls the entire content out of view.)

We currently have an interim fix that simply skips the block containing the newScrollPos = calculateScrollPos(...) if display.scroller.clientHeight is 0. I can submit that as a pull request, but I suspect it's not the fix you'd want long term, because you probably do eventually want to scroll the cursor into view once the editor becomes visible again. (In our case, we don't happen to need that right now.) So perhaps you'd want to keep a flag indicating that the scroll should happen on the next refresh() (if the editor is visible at that point).

@marijnh
Copy link
Member

marijnh commented Feb 13, 2013

Good point. As for the 'proper' solution -- I'm not sure that'd be worthwhile. Properly making sure the scroll position of a hidden editor ends up at the place where it would be if it wasn't hidden would require somehow tracking all actions that might influence scroll position, and playing them back when the editor is un-hidden. Seems like that'd be a lot of code for a very obscure use case.

If you submit your simple patch, I'll gladly merge it.

@njx
Copy link
Author

njx commented Feb 16, 2013

Submitted as #1256.

Regarding the "proper" solution, I was thinking of something fairly simple--basically, add a flag that would be set in endOperation() when a selection change would require a scroll-into-view while the editor was invisible, and then make it so on the next refresh(), if that flag was set and the editor is now visible, then scroll the current selection into view.

Alternatively, maybe it would be good enough to just expose a parameter to refresh() that would force the cursor to scroll into view if it's not already visible, so that clients could pass it when they know they're re-showing an invisible editor.

@marijnh
Copy link
Member

marijnh commented Feb 18, 2013

The problem is that if someone calls, for example, scrollTo when in a hidden state, that should, if we want to accurately simulate persistent scroll positions, also be somehow saved, and clear the flag for scrolling to the cursor, etc. I feel this'll take more code than justified.

Instead of adding a boolean flag to refresh, I think the fact that people can simply call cm.scrollIntoView(cm.getCursor()) before refreshing should be sufficient.

I've merged your patch.

@marijnh marijnh closed this as completed Feb 18, 2013
@njx
Copy link
Author

njx commented Feb 19, 2013

Makes sense. Thanks.

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

No branches or pull requests

2 participants