Bugzilla – Full Text Bug Listing
| Summary: | Search Files dialog behaves poorly when correcting text. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mike Wilson <Mike_Wilson> | ||||
| Component: | Editor | Assignee: | libing wang <libingw> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | libingw, mamacdon, simon_kaegi | ||||
| Version: | unspecified | Flags: | mamacdon:
review+
simon_kaegi: review+ |
||||
| Target Milestone: | 3.0 RC3 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
I could always reproduce the multiple "Search for..." part and sometimes(quite often) "syntaax" part. The file name search(CTRL+SHIFT+F) is much faster than keyword search so we did not notice the lagging issues before the keyword search was put into the find dialog. I remember that for the file name search(CTRL+SHIFT+F) in a non-index file system, I put an waiting gesture on the right of the search field, but it seems now the gesture is gone for that. Maybe a regression? I will roll that back and I think we can use the same waiting/timer mechanism that was used for the crawling file name search. Tested the CTRL+H on an HTML5 local file system: 1.When the dialog opens, it builds the file skelton. But this should be only for the file name search. 2.It always searches for file name, not the keyword. Issue 1 is easy to fix but issue 2 will be really hard. We can't expect the on-the-fly crawler search. So I think we should disable the on the fly search. Pushed the fix into remote branch Bug410889. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=a59f9a93424266afab4d30276c14885d9e05b454 Tested. + Pushed. |
Created attachment 232417 [details] Search Files dialog in bogus state 1) Hit Cmd-H to open new Search Files dialog 2) Type some characters that won't match files in your workspace 3) Delete characters, then type correct text. It seems there are timing issues with the threads that search for results. I have seen more than one "Searching for..." message displayed simultaneously, and sometimes this leaves you in a state where the previous search results replace the correct ones. So for example, I typed "Syntaax", then quickly corrected it to "Syntax". There should have been several matches found for Syntax, but instead the dialog displayed "No matches found for Syntaax". See the attached screen shot. Note this doesn't always happen, but I was able to cause the error several times in 10 minutes of testing. (Tried in both Safari and Chrome)