Open Bug 622801 Opened 14 years ago Updated 2 years ago

Find / Find as you type - finds the string, but the found string is not visible (covered by the "position:fixed" DIV)

Categories

(Toolkit :: Find Toolbar, defect, P5)

defect

Tracking

()

People

(Reporter: firefox, Unassigned)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13

if there is a position:fixed DIV on the top, find (or find as you type) will highlight the found string (also on the top but hidden under the position:fixed DIV), but it will be obscured by the position:fixed DIV.

it seems to the user as there is no such a string, as there is no highlighting visible

Reproducible: Always

Steps to Reproduce:
1. start typing (find as you type is enabled) to enter the string that is in the contetn of the displayed webpage
2. string will be found/highlighted but obscured by the fixed DIV, so basically not visible to the user
Actual Results:  
string not found (hidden under position:fixed DIV)

Expected Results:  
string found and displayed, not obscured/hidden by the position:fixed DIV

firefox should scroll page by one line below the fixed DIV to display the string hidden by the DIV
Version: unspecified → 3.6 Branch
I agree, Firefox should scroll down while the results are hidden by an element in position fixed.

Is it possible to fix it ?

Another way to reproduce it : 
1. Go to this page : http://twitter.com/#!/firefox
2. do CTRL-F
3. type "Firefox" in the find bar
4. click on previous several time, until the results are hidden by the top-bar

Thanks
This problem is still present in Firefox 5. It can be reproduced on http://www.allocine.fr/ e.g. by searching for "les meilleurs" and doing Ctrl-G to find the next match several times until reaching the first match again.
I confirm. Although totally minor inconvenience, it should be fixed ASAP as it must be really easy to do so.
Version: 3.6 Branch → 5 Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
It seems that Facebook, Google+, Twitter, CNET.com have all (recently?) moved to a design featuring fixed-position headers or footers.

For comparison/implementation, Google Chrome's Find in page seems to scroll such that the highlighted result is in the center of the window, which practically avoids this issue almost everywhere.  This would probably be the simpler way to implement as it is agnostic of the page contents.  IE8 seems to scroll to allow just enough room above/below the highlighted result to stand clear of any fixed-position element.
OS: Linux → All
Hardware: x86 → All
Version: 5 Branch → Trunk
Same problem with http://thesaurus.com/: the search bar at the bottom of the page, which is displayed after the first search hides results regarding text under that bar. 

Aurora 11.0a2 (2011-12-31) on Windows Vista
Related bugs:
bug 305381, bug 407817; bug 592336, bug 647708, bug 809881.
Component: General → Find Toolbar
Product: Firefox → Toolkit
Priority: -- → P5

11-years old bug with very little activity... maybe a blatant use case will help?

The problem is that found text is not highlighted in hidden/invisible elements, such as collapsed sections. For example, search for "IRS" on this page. There are over 100 occurrences, and only 3 are visible. The rest are in the collapsed sections on the right ("News", "Commentary" etc.)

This makes for a very frustrating search experience.

Would it be possible to traverse the DOM tree up from the found element and highlight the first visible element?

See Also: → 407817
Severity: minor → S4

The severity field for this bug is relatively low, S4. However, the bug has 3 duplicates.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(enndeakin)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: