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: | Search action at first hit are wrong | ||
|---|---|---|---|
| Product: | editor | Reporter: | tbrunhoff <tbrunhoff> |
| Component: | Search | Assignee: | Milutin Kristofic <mkristofic> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | dstrupl, jrojcek, mmetelka |
| Priority: | P2 | ||
| Version: | -S1S- | ||
| Hardware: | PC | ||
| OS: | Windows 7 x64 | ||
| Issue Type: | DEFECT | Exception Reporter: | |
Jano, I think this requires your attention. Please give me a spec how the search should behave. BTW I am not sure Firefox is older than NB ;-) As I pointed out to Jano (he did not agree though) the real veterans in this area are vi, emacs, joe and similar ... mozilla got started in 1998 and netbeans became open source in 2000, so you could be right about what predates what. This bug (and thanks for considering the submission) is more about the search-as-you-type feature which is more recent than that, I think. Neither vi nor emacs move the viewport until you hit enter, so I don't think they have any influence on this issue. Nor does visual studio. An important influence is whether the NB search semantics suprise the user, because surprises in a user interface are not good. The good questions are: did the NB search semantics change at some point? If so when and why? Yes, all browsers I've checked (Firefox, IE, Chrome, Safari) use the same Find semantics as you requested. The notable difference between source code and web page is the page length and content complexity. This difference means there is almost no need to "cancel" searching and get back to the original position in a browser page. It is much different in the source code where the need to get back to the original place is much stronger, if the searched term isn't present in the source code but the find feature already scrolled away from the original place many pages away. As the Find behavior in all browser is consistently the same, developers starting with NetBeans may expect similar behavior. Therefor the question is whether there is an intuitive solution how to add the required cancel behavior without using the ESC button which is reserved for closing the search box in web browsers. I don't have a definite answer to that. I would say that "Navigate | Back" should do the job of getting back to the original location after closing the search box with ESC (when considering browser-like ESC behavior). But in order to do that we would need to extend the Back action behavior. The Back action should be updated anyway as it doesn't handle well manual switching between editor tabs. It also doesn't work with other navigation actions like Go to Line, or Next and Previous Error. I would suggest to add this issue as related to an overall Back/Forward action revamp, if there is such issue already filed. If not, we should file it as we used to have a record on that somewhere on our wiki. Also, it would be interesting to do a research on similar Find feature in different source code editors. As I mentioned above, I thought that these (unexpected) search semantics are new to 7.0. If this is true, all the users that have gotten used to the search semantics in 6.5 through 6.9 will be surprised by these new semantics in 7.0, that will then be removed in 7.1. That would be bad. Please confirm that I can't remember very far back and that NB has always had the same non-web-browser-compatible search semantics. Otherwise, I think you should reconsider fixing this before 7.0 releases. I have overlooked the fact you mentioned it was actually a change in the behavior. I checked NB 6.9.1 and it really behaves differently. In 6.9.1, Cancel doesn't return to the original caret location. It is possible that the change for 7.0 wasn't really intentional. If it is the case, then it should be fixed for 7.0. Rising priority to P2 as this is a very often used feature and unintentional change in behavior should be rolled back. This still really bugs me, and the contributors above all seem to agree this needs to be fixed. But somehow, this bug was marked closed/fixed. Reopening. This is still present in ... Product Version: NetBeans IDE Dev (Build 201203210400) Java: 1.6.0_23; Java HotSpot(TM) Client VM 19.0-b09 System: Linux version 2.6.35.14-106.fc14.x86_64 running on i386; UTF-8; en_US (nb) User directory: /home/toddb/.netbeans/dev Cache directory: /home/toddb/.cache/netbeans/dev There will be two options after Bug #210700 In current build your firefox search is a default search behavior. *** This bug has been marked as a duplicate of bug 208312 *** |
For some time now, the search semantics in NB have bugged me, and I wasn't sure why I could not adapt. Finally I realized that other well-established software use search semantics that differ from NB. Let me illustrate. - open a file that has at least twice as many lines as what's available in the editor. - find a unique string that first occurs in the second screen or later. - scroll to the top of the file, hit control-f, and type in the unique string. - At this point NB has already scrolled to the point of the unique string (which is very useful), but you are still in the search box. This issue is the actions taken when you hit escape or enter. If I hit escape the screen flies back to the view before the search began. If I hit enter, NB makes no visual change on the screen but the current selection and view become the current one. Although I can see the value of this (aborting a search and returning to where you started), NB's actions differ from netscape and internet explorer which have been in place far longer than NB. Compare the actions at the point when the first enter or escape is hit during a search: Enter Escape +----------------+-----------------------+ | no movement | close search & | NB | "accept" first | fly back to search | | search hit | start point. | +----------------+-----------------------+ Firefox| move to second | close search & remain | & IE | search hit | at first search hit | +----------------+-----------------------+ IIRC, I think that NB used to have the same search semantics as firefox and IE. I think the correct solution is to switch back to the mainstream search semantics. I also think there is value in being able to abort a search and return to the start point. I think that could be preserved with adding a hot key to do this, and perhaps even a tiny abort button next to the search box with a flyover that says what the abort hot key is. I set this to P2 because I think the current search actions are too different from well established practice.