Closed Bug 172560 Opened 20 years ago Closed 20 years ago

Typeaheadfind stops on visibility:hidden, visibility:collapse

Categories

(SeaMonkey :: Find In Page, defect, P2)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.2beta

People

(Reporter: bugzilla, Assigned: aaronlev)

References

()

Details

Attachments

(2 files)

The type ahead feature allows a user to navigate to a link in a hidden element.
On the example URL there are several hidden elements (due to a dynamic popup
menu).  Try typing "onl" and watch the cursor stop at the upper left corner,
where the hidden link is located.
Expected behaviour: Type Ahead should ignore links in hidden elements.
I'm finding that text with regular find too -- how has it been hidden, with
zindex or something?

I thought the following code might help, but it didn't. The frame being returned
by nsIFind is being reported as visible.

    PRBool isFinished = PR_FALSE, isVisible = PR_FALSE;
    frame->CheckVisibility(aPresContext, startFrameOffset, endFrameOffset, 
                           PR_FALSE, &isFinished, &isVisible);
    if (!isVisible) {
      return PR_FALSE;
    }

Status: UNCONFIRMED → NEW
Ever confirmed: true
Just checked, and it's not being hidden with zindex. I guess I'll have to comb
through the source to find out what they're doing to hide that text, unless
someone else knows.
Ugh, HTML Tidy won't even clean up the source for this page.
Aha, the problem is that nsIFind returns results with both visibility:hidden and
display:none frames.

Webbrowserfind doesn't check it either.

Summary: Type Ahead stops on hidden links → Typeaheadfind/find both stop on visibility:hidden,
How should we fix it?
1. Patch both nsTypeAheadFind.cpp and nsWebBrowserFind.cpp to look for
visibility:hidden and display:none?
2. Patch nsFind.cpp to take care of it for all consumers of it?

Also, shouldn't nsIFrame::CheckVisibility() tell return isVisible = PR_FALSE
when visibility:hidden is set on the frame?
visibility:collapse is also a problem.
Summary: Typeaheadfind/find both stop on visibility:hidden, → Typeaheadfind/find both stop on visibility:hidden, visibility:collapse
I would guess that things hidden by zindex would be found as well.
isn't this related to an old Find bug where Find locates stuff in (for example)
js script content (which isn't rendered on the page)?
nsFind doesn't appear to talk with layout at all. Is it supposed to limit itself
to what's visible in the document? There can be all kinds of content that's
hidden waiting for some script to bring it forward.
Blocks: isearch
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.2beta
Seeking r=/sr=
I'm going to file a separate bug for regular dialog find
Summary: Typeaheadfind/find both stop on visibility:hidden, visibility:collapse → Typeaheadfind stops on visibility:hidden, visibility:collapse
Comment on attachment 101945 [details] [diff] [review]
Checks css visibility in IsRangeVisible()

r=kyle. same comment as for bug 172656.
Attachment #101945 - Flags: review+
Comment on attachment 101945 [details] [diff] [review]
Checks css visibility in IsRangeVisible()

sr=alecf
Attachment #101945 - Flags: superreview+
Forgot to mark this fixed, it was checked in a while ago.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
the attached testcase is the wrong mime, but the test url works. vrfy'd with
2002.11.19 comm trunk bits.
Status: RESOLVED → VERIFIED
OS: Windows 2000 → All
Hardware: PC → All
Component: Keyboard: Navigation → Keyboard: Find as you Type
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.