This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
|Summary:||Editor scrolls back on Escape after partial match with Ctrl+F search|
|Component:||Search||Assignee:||Milutin Kristofic <mkristofic>|
|Severity:||normal||CC:||bht, ebakke, ralphbenjamin, tbrunhoff|
|Issue Type:||DEFECT||Exception Reporter:|
Description ebakke 2012-02-13 06:10:13 UTC
The best way to explain this bug is to explain how to reproduce it: 1) Open a text file (or Java source code file or whatever), several pages long, in a NetBeans IDE editor. 2) At the end of the file, write, for the purposes of this example, the word "supercalifragilistic". Scroll back up to the top of the file. 3) Now press Ctrl+F to open the "Find" box. Type in "supercali". The editor will scroll down to where the word "supercalifragilistic" is located in the file. Don't exit the find box yet. 4) Now type the character "t", so that the entire search phrase is "supercalit". The match will now fail, but the editor is still scrolled to the bottom of the file. 5) Now press escape to exit the search box. Here is the bug: The editor now scrolls back to the top where the cursor originally were. The expected behavior is that the editor should stay scrolled to the bottom of the screen. It's quite possible that someone made a concious decision to make the editor scroll back to wherever it was before the search was started, in the case where the final search phrase does not appear anywhere in the document being edited. Arguably, however, the better behavior is to keep the editor scrolled to where the last partial match was located. This is the behavior of Ctrl+F search in both Chrome, Firefox, and Internet Explorer--all applications that we'd expect developers to be switching back and forth to while using the NetBeans IDE. Regardless of independent merits of the current NetBeans editor's behavior, I'd say it's more important to behave the same way as other frequently used applications. Plus, the web browsers' behavior is arguably better because it doesn't punish users for making spelling mistakes late in a long search term being typed into the search box--often there will be a match after only a few characters has been typed.
Comment 1 ebakke 2012-02-13 06:51:46 UTC
A related issue: It seems that if you enter a search term and press escape, the cursor will remain wherever it was before the search was started, even though the entire search string was matched and the editor was scrolled to the match. In other words, the cursor will suddenly be out of view of the editor, which is very unlikely to be the intended behavior. (I can file this as a separate bug if desired.)
Comment 2 Milutin Kristofic 2012-02-13 10:49:33 UTC
Without pressing Enter, it's just preview search. If you want jump to some position, search item, press enter and then escape.
Comment 3 ebakke 2012-02-13 16:42:48 UTC
@mkristofic Hmm, such "preview search" semantics are inconsistent with how other applications with a search bar work, though, so it becomes a point of pain instead of a utility. When you press "enter" in Chrome after a search, for instance, the cursor goes to the _next_ match. So you wouldn't want people to get in a habit of pressing enter before pressing escape--then they'd be doing it right in NetBeans, but wrong in their web browser. When you press escape in Chrome, the search box simply disappears, without any scrolling. Like in the browsers, I'd say pressing escape should never move the scroll viewport--it startles me every time :-)
Comment 4 Vladimir Voskresensky 2012-02-14 13:03:08 UTC
I agree with ebakke and for me the most comfortable way would be: on Esc do like browsers - leave view on the first found selected word and leave cursor in selected word as well BUT remember last cursor position to be able jump back with Alt+LEFT/RIGHT after Esc from Find panel
Comment 5 Ralph Ruijs 2012-02-21 10:30:05 UTC
Currently it jumps to the cursor position, instead of the last viewport. Steps to reproduce: Open a file Scroll to somewhere else Press Ctrl+F and directly press Escape It would be great if this could be the same as in other applications as described by ebakke.
Comment 6 Milutin Kristofic 2012-03-28 14:28:03 UTC
This is a quite big change. 1, After escape view is not jumping (this happen by accident probably from Bug # #201558) 2. When incremental search (without enter) is selecting first match 3. Enter (next button) is just next match http://hg.netbeans.org/jet-main/rev/2da4bf27dcc7
Comment 7 Milutin Kristofic 2012-04-02 09:53:44 UTC
*** Bug 210483 has been marked as a duplicate of this bug. ***
Comment 8 Milutin Kristofic 2012-04-10 14:02:25 UTC
*** Bug 195580 has been marked as a duplicate of this bug. ***
Comment 9 ebakke 2012-07-08 05:29:22 UTC
I just tried NetBeans 7.2rc1 and was very happy to see the new "Editor Search Behavior" option (with Firefox-like behavior, my personal preference, as the default). Awesome--thank you for doing this! There's one little detail that's still not consistent with the behavior of Ctrl+F search in web browsers, though. If the "Find" box in the search bar contains a search term, and the user presses escape to close the search bar, and then presses Ctrl+F to open it again, a search will actually be made immediately as Ctrl+F is pressed, possibly scrolling the editor viewport. In both Chrome, Firefox, and Internet Explorer, pressing Ctrl+F will do nothing else than actually make the search bar visible; the user has to press enter to make an actual search. If you want I can file a separate new bug about this. But thanks again for doing the work to fix this bug!
Comment 10 bht 2012-07-08 07:04:00 UTC
Options|Editor|General|Search lets you change the search behavour
Comment 11 ebakke 2012-07-08 07:45:19 UTC
@bht Yes, my previous comment described current behavior with "Enter to find next" selected under Tools->Options->Editor->General->Search->Editor Search Behavior. Even with "Enter to find next", the initial Ctrl+F that opens the search bar actually changes the editor selection and scrolls the viewport as well (none of the web browsers do this).
Comment 12 bht 2012-07-08 09:55:01 UTC
I see. Perhaps you want to file a bug for this. The browser bahaviour you describe is probably more correct. To describe this one could say to execute a search, an event is required. With a new search, the event is the typing. The opening of a seach bar cannot be seen as an equivalent event.
Comment 13 ebakke 2012-07-08 21:45:23 UTC
@bht: OK, I added a new bug at http://netbeans.org/bugzilla/show_bug.cgi?id=215260 . Thanks!