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 | ||
---|---|---|---|
Product: | editor | Reporter: | ebakke |
Component: | Search | Assignee: | Milutin Kristofic <mkristofic> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bht, ebakke, ralphbenjamin, tbrunhoff |
Priority: | P3 | ||
Version: | 7.1 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
ebakke
2012-02-13 06:10:13 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.) Without pressing Enter, it's just preview search. If you want jump to some position, search item, press enter and then escape. @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 :-) 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 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. 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 *** Bug 210483 has been marked as a duplicate of this bug. *** *** Bug 195580 has been marked as a duplicate of this bug. *** 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! Options|Editor|General|Search lets you change the search behavour @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). 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. @bht: OK, I added a new bug at http://netbeans.org/bugzilla/show_bug.cgi?id=215260 . Thanks! |