Bugzilla – Full Text Bug Listing
| Summary: | Race condition with Find toolbar and editor | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mark Macdonald <mamacdon> | ||||
| Component: | Client | Assignee: | Project Inbox <orion.client-inbox> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | libingw, Silenio_Quarti | ||||
| Version: | 4.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Mark Macdonald
Not sure if we should do this: Put editor into readonly mode as soon as CTRL+F got hit. Set editor back to writable mode when the slide out is loaded. I believe there must be other similar racing cases when you type something outside of editor. I've seen this happen also. I'm wondering what would be the fix. Maybe put the focus somewhere else immediately and then to the find box once it's there? It would be interesting to try the same test with Goto Line and see if you can make it happen. (In reply to comment #2) > It would be interesting to try the same test with Goto Line and see if you can > make it happen. Just tried this out, and yes: the same race happens with the Goto Line param collector too. This sounds like a good RCx kind of bug, there is probably something I could do to put focus to some dead space. The keys would still be eaten but at least the editor wouldn't take them. moving to RC2 for triage after the test pass. Mark, do you find this improved at all? It's weird, sometimes I can reproduce this at will (on first load) and then just now when trying out some ideas I can't reproduce it at all (on first load). I think the fundamental issue is that the text action is invoking commandService.runCommand which is asynch so the slideout is not going to open synchronously when handling the key. I was playing around with putting the focus immediately somewhere else before invoking the command but then I just had trouble making the original happen reliably in order to test the fix. moving milestone to 2.0 M1 for future triage. I changed commandService.runCommand so that it's not asynchronous. I'm pretty sure this was originally asynch to allow some BorderContainer related layout to catch up with the slideout being open. I removed the timeouts and tested the calling cases (editor find, editor goto line, and create new content templates). Everything seems fine without the timeouts. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=1ee03af1b722951282c9a5bdbe2d2e607e3f874c So, I'm pretty sure this is resolved, at least I wasn't able to make it happen in master and I am able to make it happen in the build. Mark, I may ping you to try to break it when it gets in the build to be sure this is fixed. Reopening. I regularly encounter this bug in Orion 4.0. Here is the procedure: 1. Open a file in the Orion editor ( eg. edit.html#/some/file/url.js ) 2. Immediately after the editor comes up, press Ctrl+F. The Find toolbar should appear. 3. After a moment, the Find toolbar vanishes. The editor regains keyboard focus. 4. Now your keystrokes go into the buffer, rather than the find toolbar. I have no idea why the Find toolbar goes away in Step 3, but it's driving me nuts. I start trying to type in the toolbar, but it goes away and I mess up the editor instead. This is probably happening because of this change: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=3cb9ad967c8f157db9412a3ada5ab4d2aae3b313 The change was made because the parameter collector would stay open when the folder view showed (when opening a directory with readme.md). I changed master to only close it when the type of editor changes. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=de07e86986b0bc69157f0c00d1a0c92c500471bf I was not able to reproduce the problem though. Please try the latest and re open if it still happens for you. (In reply to Silenio Quarti from comment #10) > http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/ > ?id=de07e86986b0bc69157f0c00d1a0c92c500471bf > > I was not able to reproduce the problem though. Please try the latest and re > open if it still happens for you. This didn't fix it for me. I can show you IRL. Reproduced it. Here is the stack: CommandParameterCollector.close (parameterCollectors.js:42) CommandRegistry.closeParameterCollector (commandRegistry.js:255) fileCommandUtils.updateNavTools (fileCommands.js:132) objects.mixin.updateCommands (mini-nav.js:256) (anonymous function) (mini-nav.js:81) (anonymous function) (EventTarget.js:43) EventTarget.dispatchEvent (EventTarget.js:40) Selection.setSelections (selection.js:85) exports.ExplorerRenderer.ExplorerRenderer._restoreSelections (explorer.js:557) exports.ExplorerRenderer.ExplorerRenderer._initializeUIState (explorer.js:689) exports.Explorer.Explorer.createTree (explorer.js:185) (anonymous function) (explorer-table.js:584) notify (Deferred.js:111) run (Deferred.js:30) enqueue (Deferred.js:43) Deferred.resolve (Deferred.js:159) _messageHandler (pluginregistry.js:389) (anonymous function) (pluginregistry.js:1036) _messageHandler (pluginregistry.js:1031) Ah, so the culprit would be the sidebar trying to update its commands as it finishes loading the directory contents? Seems like it. The problem is that the slide out does not belong to the sidebar, but the sidebar closes it anyways. We need some way of determining how owns the slide out it. Another case the editor parameter collect gets closed because of updateNavTools(). 1) Open editor and open find slide out 2) Change the directory shown in the sidebar (click the go into arrow for example) Created attachment 235404 [details]
work in progress
This patch fixes this specific problem, but I am not sure what side effects it could cause.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |