Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in mozilla12

Status

()

Core
Find Backend
P3
enhancement
RESOLVED FIXED
15 years ago
5 years ago

People

(Reporter: Sander, Assigned: Ehsan)

Tracking

(Blocks: 2 bugs, {dev-doc-complete, ue, user-doc-needed})

Trunk
mozilla12
dev-doc-complete, ue, user-doc-needed
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-Opera] [parity-Safari])

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
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.
(Reporter)

Updated

15 years ago
Blocks: 30088

Updated

15 years ago
Status: NEW → ASSIGNED
Component: XP Apps → Keyboard Navigation
Priority: -- → P3
Target Milestone: --- → mozilla1.3alpha

Comment 1

15 years ago
Regular find has the same problem.

Comment 2

15 years ago
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

Updated

15 years ago
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

Updated

15 years ago
Component: Keyboard: Navigation → Keyboard: Find as you Type

Comment 3

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

Comment 4

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

Comment 5

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

Updated

12 years ago
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

Comment 6

12 years ago
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

Comment 7

12 years ago
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.  

Comment 8

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

Comment 9

12 years ago
Masayuki, are you interested in fixing this bug?

Comment 10

12 years ago
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. ***

Comment 12

11 years ago
I'll take this on the off chance I get to it at some point soon.
Assignee: aaronleventhal → pkasting
Status: ASSIGNED → NEW

Comment 13

11 years ago
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?

Comment 15

11 years ago
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

Updated

10 years ago
Duplicate of this bug: 389109
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-

Comment 20

10 years ago
(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)

Updated

10 years ago
Duplicate of this bug: 412334

Updated

10 years ago
Duplicate of this bug: 415739

Updated

9 years ago
Duplicate of this bug: 440198
Flags: wanted1.9.1?
Keywords: ue
Whiteboard: [parity-Opera] [parity-Safari]
Product: Core → SeaMonkey

Updated

7 years ago
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

Updated

7 years ago
Blocks: 565552

Comment 24

7 years ago
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.
Duplicate of this bug: 471032
Duplicate of this bug: 577866

Comment 27

7 years ago
> 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!
Duplicate of this bug: 397898

Updated

7 years ago
Blocks: 631270

Comment 29

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

Comment 30

6 years ago
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.

Comment 32

6 years ago
(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.

Comment 33

6 years ago
(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.

Comment 34

6 years ago
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.

Comment 35

6 years ago
(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.
(Reporter)

Comment 36

6 years ago
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.

Comment 37

6 years ago
> 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.

Comment 38

6 years ago
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).

Comment 39

6 years ago
(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.

Updated

6 years ago
Duplicate of this bug: 706038
Created attachment 587591 [details] [diff] [review]
Patch (v1)

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)
Attachment #587591 - Flags: review?(roc) → review+
Created attachment 587790 [details] [diff] [review]
Part 2

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)
Attachment #587790 - Flags: review?(roc) → review+
Keywords: dev-doc-needed, user-doc-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/fb7a018387f9
https://hg.mozilla.org/integration/mozilla-inbound/rev/91ed31395881
Target Milestone: Future → mozilla12

Comment 44

6 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
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!

Comment 47

6 years ago
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
Duplicate of this bug: 440198

Comment 49

6 years ago
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).

Comment 50

6 years ago
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.

Comment 51

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

Updated

6 years ago
Depends on: 720126

Comment 52

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

Comment 53

6 years ago
(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.

Comment 54

6 years ago
(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.

Comment 55

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

Updated

6 years ago
Blocks: 640132

Updated

6 years ago
Blocks: 658937

Updated

6 years ago
Blocks: 707963
Duplicate of this bug: 653241

Updated

6 years ago
Blocks: 631250

Comment 57

6 years ago
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.

Updated

5 years ago
Blocks: 743103
Documentation updated:

https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISelectionController#Scroll_constants

And mentioned on Firefox 12 for developers.
Keywords: dev-doc-needed → dev-doc-complete

Updated

5 years ago
Blocks: 748991

Comment 59

5 years ago
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).

Comment 61

5 years ago
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.