Closed Bug 171237 Opened 22 years ago Closed 12 years ago

Find in Page: highlighted result should be at the middle of the page (vertically centered) instead of last line/bottom of page

Categories

(Core :: Find Backend, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla12

People

(Reporter: svl-bmo, Assigned: ehsan.akhgari)

References

(Blocks 2 open bugs)

Details

(Keywords: dev-doc-complete, ue, user-doc-needed, Whiteboard: [parity-Opera] [parity-Safari])

Attachments

(2 files)

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.
Blocks: isearch
Status: NEW → ASSIGNED
Component: XP Apps → Keyboard Navigation
Priority: -- → P3
Target Milestone: --- → mozilla1.3alpha
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.
Keywords: helpwanted
Target Milestone: mozilla1.3alpha → Future
Summary: Move view a few lines beyond occurance of found search term with type ahead find → Move view a few lines beyond occurence of found search term with type ahead find
Component: Keyboard: Navigation → Keyboard: Find as you Type
*** 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. ***
Summary: Move view a few lines beyond occurence of found search term with type ahead find → Scroll view a few lines beyond occurence of found search term with type ahead find
Please correct the subject: occurence -> occurrence.
Summary: Scroll view a few lines beyond occurence of found search term with type ahead find → Scroll view a few lines beyond occurrence of found search term with type ahead find
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.
Assignee: aaronleventhal → pkasting
Status: ASSIGNED → NEW
See also bug 355229, same bug for scrolling to #named_anchor.
*** Bug 361275 has been marked as a duplicate of this bug. ***
Flags: blocking1.9?
Not going to be getting to this one.
Assignee: pkasting → nobody
QA Contact: pawyskoczka → keyboard.fayt
isn't Chris' patch from bug 78833 comment 20 a good starting point?
Summary: Scroll view a few lines beyond occurrence of found search term with type ahead find → Scroll view a few lines beyond occurrence of found search term with type ahead find to show more context instead of bottom of page
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.
Flags: blocking1.9? → blocking1.9-
(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)
Flags: wanted1.9.1?
Keywords: ue
Whiteboard: [parity-Opera] [parity-Safari]
Product: Core → SeaMonkey
Component: Find In Page → Find Backend
Product: SeaMonkey → Core
QA Contact: keyboard.fayt → find-backend
Blocks: 440198
Keywords: helpwanted
Summary: Scroll view a few lines beyond occurrence of found search term with type ahead find to show more context instead of bottom of page → Scroll view a few lines beyond occurrence of found search term with type ahead find and toolkit find to show more context instead of last line/bottom of page
Blocks: 565552
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!
Blocks: 631270
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.
Attached patch Patch (v1)Splinter Review
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!  :-)
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #587591 - Flags: review?(roc)
Attached patch Part 2Splinter Review
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.
Attachment #587790 - Flags: review?(roc)
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
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.
Flags: wanted1.9.1?
Summary: Scroll view a few lines beyond occurrence of found search term with type ahead find and toolkit find to show more context instead of last line/bottom of page → Find in Page: highlighted result should be at the middle of the page (vertically centered) instead of last line/bottom of page
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.
Depends on: 720126
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.
Blocks: 640132
Blocks: 658937
Blocks: 707963
Blocks: 631250
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.
Blocks: 743103
Blocks: 748991
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.
You need to log in before you can comment on or make changes to this bug.