One the the biggest practical annoyances with the otherwise wonderful type ahead find is that when the next occurance of a searchterm is found, it's located on the very last line visible in the window. Particularly when searching through all text (instead of just through links) chance are you will want to read on for at least one or two more lines to see if this occurance is really relevant for what you're looking for, or if you want to hit F3. I don't think the occurance should appear anywhere near the middle of the screen, as then spotting the selected text isn't as instantanious as it is now, but I do think it would be good if the view could move on at least a few lines.

Regular find has the same problem.

nsPresShell.cpp's nsISelectionController:ScrollSelectionIntoView() calls nsSelection.cpp's nsIFrameSelection::ScrollSelectionIntoView() calls nsTypedSelection::ScrollIntoView() calls nsTypedSelection::ScrollRectIntoView() which takes arguments aVPercent and aHPercent, what percent vertically or horizontally to position at (or NS_PRESSHELL_SCROLL_ANYWHERE). We could use the aVPercent argument to get this done, but none of the other interfaces currently support that, we'd need to change them all.

*** Bug 78833 has been marked as a duplicate of this bug. ***

*** Bug 270124 has been marked as a duplicate of this bug. ***

*** Bug 263447 has been marked as a duplicate of this bug. ***

Please correct the subject: occurence -> occurrence.

As indicated in bug #78833 (closed as a duplicate of this later bug), a forward Find that requires a scroll should position the found string a few lines below the top of the window. Then, subsequent Find operations for nearby instances of that same string might not require additional scrolling. This allows the user a better view of the context of multiple instances of the target string. Similarly, a backward Find should position the found string a few lines above the bottom of the window.

*** Bug 286851 has been marked as a duplicate of this bug. ***

Masayuki, are you interested in fixing this bug?

It could also be possible to make the highlighted text be positioned in the middle of the of the window. This is done this way also in several other applications and gives a good overview over the page, too. Additional there would be no difference between backwards- and forward-searching that may confuse the user.

*** Bug 322479 has been marked as a duplicate of this bug. ***

I'll take this on the off chance I get to it at some point soon.

See also bug 355229, same bug for scrolling to #named_anchor.

*** Bug 361275 has been marked as a duplicate of this bug. ***

Not going to be getting to this one.

isn't Chris' patch from bug 78833 comment 20 a good starting point?

I use the code on this page http://forums.mozillazine.org/viewtopic.php?p=2824788#2824788 for quite some time, and it works excellent. I even nearly forgot that it's not Firefox doing that job... Maybe if the author agrees, it could be integrated in Firefox?

We might still accept a patch for M8 or even M9 if it's low-risk.

(In reply to comment #18) > I use the code on this page > http://forums.mozillazine.org/viewtopic.php?p=2824788#2824788 for quite some > time, and it works excellent. I even nearly forgot that it's not Firefox doing > that job... Maybe if the author agrees, it could be integrated in Firefox? > That requires the userChrome.js extension (see also bug 332529)

This also can become a problem if a website includes a floating "toolbar" which it keeps stuck in place at the bottom (or top, if scrolling upwards to a previous search result) of the content window, as this will result in the found term being scrolled underneath the "toolbar" and out of the user's sight and click space.

> I don't think the occurance should appear anywhere near the middle of the > screen, as then spotting the selected text isn't as instantanious as it is now, > but I do think it would be good if the view could move on at least a few lines. I don't agree. The text should appear (when possible) exactly in the center of the screen. One then gets to see the maximum context possible. One also knows exactly where it will appear. There is also then no bias by the programmer about directionality in the text. As for noticing the text - take a look at what the PDF reader skim does. It highlights the text brightly and then that fades to an ellipse around the text. You can't miss it!

Under Firefox 4, UI experience is worse with highlighted links that found. The "status bar" appears over searched text!

chbok, that sounds like bug 640132. While it's true that fixing this bug would take of the overlap in many cases, it wouldn't fix it the case where the found text is at the bottom of the page (so there's no more room to scroll).

(In reply to comment #30) Well, if you read bug 640132 comment 3 you can resolve this adding a padding at the end of the page if the search reaches the end. I want to suggest the padding can be used also to _centre_ that search.

(In reply to comment #31) > (In reply to comment #30) > Well, if you read bug 640132 comment 3 you can resolve this adding a padding at > the end of the page if the search reaches the end. I want to suggest the > padding can be used also to _centre_ that search. Looks like bug 441098.

(In reply to comment #32) > cc: RNicoletto@gmail.com(In reply to comment #31) > > (In reply to comment #30) > > Well, if you read bug 640132 comment 3 you can resolve this adding a padding at > > the end of the page if the search reaches the end. I want to suggest the > > padding can be used also to _centre_ that search. > > Looks like bug 441098. Sorry. I mean bug 440198.

I just made this suggestion on the dev-apps forum and was directed here. This item was submitted Sept 2002. NINE YEARS AGO! It should have been a no-brainer. From all the duplicates noted it would seem that there were hundreds of others feel the same. Why the delay? I also vote for vertically centering the found text, not just a few extra scroll lines, just as (another duplicate), bug 440198 suggests.

(In reply to Sander from comment #0) > I don't think the occurance should appear anywhere near the middle of the > screen, as then spotting the selected text isn't as instantanious as it is > now, > but I do think it would be good if the view could move on at least a few > lines. I disagree. If the search ALWAYS put the result in the exact center of the screen one would always know exactly where to look! The most context maximum is the most useful.

In reply to Tom Schneider from comment #35: You wrote the same thing in comment #27 as well. No need to repeat yourself. FWIW, personally I don't have a strong feeling about it; I just think that the center is worse because 1) I for one have no idea where the exact center on my screen is (and the bigger the screen, the worse the uncertainty), while I _can_ pinpoint "two lines above the bottom" and 2) any find in the last half page of a site will appear at an unknown location (somewhere between the center and the bottom). However, whoever implements this will decide (maybe with some feedback from Mozilla UX-people). Discussing such issues beforehand only makes the bug noisier and less likely to be fixed at all.

> In reply to Tom Schneider from comment #35: > You wrote the same thing in comment #27 as well. Ha, I hadn't noticed that, sorry for the repeat. I suppose I'm consistent over long periods. As for a solution - how about making it a user determined switch? Then each person does what they want. > Discussing such issues beforehand only makes the bug noisier and > less likely to be fixed at all. Given that it's been 9 years, perhaps a discussion of this ought to be held so the issues are resolved.

I think I prefer something near the center to have the maximum context, but the best position may depend on the document. Also this bug should be fixed at the same time as bug 622801 (still UNCONFIRMED unfortunately).

(In reply to Sander from comment #36) > In reply to Tom Schneider from comment #35: > You wrote the same thing in comment #27 as well. No need to repeat yourself. > FWIW, personally I don't have a strong feeling about it; I just think that > the center is worse because 1) I for one have no idea where the exact center > on my screen is (and the bigger the screen, the worse the uncertainty), > while I _can_ pinpoint "two lines above the bottom" and 2) any find in the > last half page of a site will appear at an unknown location (somewhere > between the center and the bottom). 1) It will always be obvious where the exact center (vertically) of the screen is, because that's where the highlighted text you were searching for will be. 2) This will happen regardless of where you try to position the search result. For example, this is exactly what happens now (search result at a "unknown" location) if the search result is near the top of the page or is already visible. (Note this is about the vertical position; the search result already appears at an "unknown" location horizontally.) I haven't heard any complaining about this aspect of it's behavior, and regardless, highlighting the text goes a long way to drawing your eyes to it's location, wherever that may be.

This has always driven me nuts. Tonight it annoyed me enough that I decided that I will spend 15 minutes to fix it once and for all! :-)

This caused failures on the try server, which helped me find a bunch of stuff which I did not fix in bug 605138. They matter now since the false values will be passed in and used for vertical and horizontal percents. This patches fixes those calls.

https://hg.mozilla.org/integration/mozilla-inbound/rev/fb7a018387f9 https://hg.mozilla.org/integration/mozilla-inbound/rev/91ed31395881

Try run for f3094f75f844 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=f3094f75f844 Results (out of 211 total builds): exception: 1 success: 179 warnings: 29 failure: 2 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-f3094f75f844

https://hg.mozilla.org/mozilla-central/rev/fb7a018387f9 https://hg.mozilla.org/mozilla-central/rev/91ed31395881

I'm testing the win32 build from http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-f3094f75f844 In a word, this is outstanding! thanks ehsan!

Adjusting summary to what was done.

This will be great. It annoyed me that the found text was often hidden behind the floating link target popup (on link heavy pages like buglists).

I have found this new feature a little annoying. If you have a result within a few lines of each other then the page jumps which can be disturbing and confused me into believing that I was an entirely new place on the page when I fact it had only moved 2 lines down.

That is also true. Maybe the centering should only be done when the new match is found more than ~25% off the vertical center.

How about not moving the displayed page at all if the new match already appeared in the displayed page?

(In reply to David E. Ross from comment #52) > How about not moving the displayed page at all if the new match already > appeared in the displayed page? No because then you get huddled into the bottom of the page and the original problem occurs.

(In reply to :aceman from comment #51) > That is also true. Maybe the centering should only be done when the new > match is found more than ~25% off the vertical center. This might work! I think that one solution is to allow a set of switches so that each person can adjust it themselves. First option is the original (obnoxious in my opinion) method of always being at the bottom of the page. Second is always putting the result in the exact vertical center. Third is a distance trigger as aceman suggested.

Yes, but please discuss this in bug 720126, which was created for this problem from comment 50.

I came across another example for Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7.2 At http://www.mindscience.org/database search for the word 'prism' It is lost under the bottom bar.

Documentation updated: https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISelectionController#Scroll_constants And mentioned on Firefox 12 for developers.

Wow, a 10-year-bug fixed, congrats :-) But what if I don't like this change (and have never considered it as a bug), is there a magic about:config switch to turn the old behaviour back on?

(In reply to Christian Kujau from comment #59) > Wow, a 10-year-bug fixed, congrats :-) But what if I don't like this change > (and have never considered it as a bug), is there a magic about:config > switch to turn the old behaviour back on? There isn't; sorry. If there are specific reasons that this change bothers you, and if you think those reasons could be fixed without losing the main benefits from this change, feel free to file them as follow-up bugs. For example there is bug 720126 which is fixed in Firefox 14 (currently on the beta channel).

Thanks for pointing me to 720126, this is exactly the issue I have since this one (171237) got "fixed". I'll wait for Firefox 14 then.