-
-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Comments
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. |
Submitted as #1256. Regarding the "proper" solution, I was thinking of something fairly simple--basically, add a flag that would be set in Alternatively, maybe it would be good enough to just expose a parameter to |
The problem is that if someone calls, for example, Instead of adding a boolean flag to I've merged your patch. |
Makes sense. Thanks. |
In
endOperation()
, if the selection has changed, we callcalculateScrollPos()
to figure out how to scroll the selection into view. However, if the editor is hidden,calculateScrollPos()
returns a bogus value, becausedisplay.scroller.clientHeight
is 0. This value can end up getting saved off indoc.scrollTop
, which then messes up futurerefresh()
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(...)
ifdisplay.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 nextrefresh()
(if the editor is visible at that point).The text was updated successfully, but these errors were encountered: