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

[CLOSED] Editor scrolls back to top when returning to it after Quick Open #2785

Open
core-ai-bot opened this issue Aug 29, 2021 · 9 comments

Comments

@core-ai-bot
Copy link
Member

Issue by peterflynn
Tuesday Feb 26, 2013 at 03:05 GMT
Originally opened as adobe/brackets#2951


Finally nailed down some repro steps for this!

  1. Open file A, scroll down one or more screenfuls and place the cursor somewhere there
  2. Use Quick Open to open some other file B
  3. Switch back to file A (via whatever mechanism -- Ctrl+Tab, click in working set, etc.)
@core-ai-bot
Copy link
Member Author

Comment by pthiess
Friday Mar 01, 2013 at 18:52 GMT


Reviewed, medium priority seems reasonable,@njx

@core-ai-bot
Copy link
Member Author

Comment by peterflynn
Saturday Mar 02, 2013 at 00:51 GMT


Looks somewhat unrelated to #2985 after all. I think the bug here is that the value of getCurrentFullEditor() during the ModalBar ctor isn't necessarily the same as the value of getCurrentFullEditor() during ModalBar.close(). Because closing happens at the end of QuickOpen._handleItemSelect() and is further delayed by a timeout, it's basically guaranteed that the editor will have already switched by the time close() is called.

Things brings two questions to mind:

  • Is it even possible to restore the scroll pos of the correct editor after it's invisible? Will CM choke trying to measure something in code that was triggered by scrollTo()? Will the update stick once the editor becomes visible and gets refreshed?
  • What about the editor you were switching to? If it's also affected by the ModalBar's presence (before it closes), does that mean we have to run the restore-scroll-pos code on both editors?

@core-ai-bot
Copy link
Member Author

Comment by peterflynn
Saturday Mar 02, 2013 at 01:02 GMT


Also note: the timing of this stuff is affected by whether file B is already in the working set -- the editor switch is much more synchronous if so.

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Sunday Mar 03, 2013 at 03:21 GMT


I can still reliably reproduce this after the landing of #3023, so I guess you're right about it not being quite related.

@core-ai-bot
Copy link
Member Author

Comment by RaymondLim
Sunday Mar 03, 2013 at 03:25 GMT


@dangoor I believe the root cause of this is also causing your Quick Open unit test failing (#2696).

@core-ai-bot
Copy link
Member Author

Comment by njx
Friday Mar 08, 2013 at 01:25 GMT


Nominating for sprint 22.

@core-ai-bot
Copy link
Member Author

Comment by njx
Wednesday Mar 13, 2013 at 00:29 GMT


Turns out this is due to a subtle race condition: if you call scrollTo() on a CodeMirror instance and then immediately hide the editor before the resulting scroll events are processed, CM ends up scrolling to (0,0). I submitted codemirror/codemirror5#1350 to fix this.

@core-ai-bot
Copy link
Member Author

Comment by njx
Wednesday Mar 13, 2013 at 18:36 GMT


FBNC to@peterflynn

@core-ai-bot
Copy link
Member Author

Comment by peterflynn
Thursday Mar 21, 2013 at 22:24 GMT


Confirmed

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

1 participant