172560 - Typeaheadfind stops on visibility:hidden, visibility:collapse

Status: VERIFIED FIXED

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

Description

[Vidar S. Ramdal]

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.

Comment 1

[Aaron Leventhal]

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;
    }

Comment 2

[Aaron Leventhal]

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.

Comment 3

[Aaron Leventhal]

Ugh, HTML Tidy won't even clean up the source for this page.

Comment 4

[Aaron Leventhal]

Aha, the problem is that nsIFind returns results with both visibility:hidden and
display:none frames.

Webbrowserfind doesn't check it either.

Comment 5

[Aaron Leventhal]

Attachment: Testcase, thanks to help from doron.

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?

Comment 6

[Aaron Leventhal]

visibility:collapse is also a problem.

Comment 7

[Aaron Leventhal]

I would guess that things hidden by zindex would be found as well.

Comment 8

[sairuh (rarely reading bugmail)]

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)?

Comment 9

[Aaron Leventhal]

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.

Comment 10

[Aaron Leventhal]

Attachment: Checks css visibility in IsRangeVisible()

Seeking r=/sr=

Comment 11

[Aaron Leventhal]

I'm going to file a separate bug for regular dialog find

Comment 12

[Kyle Yuan]

Comment on attachment 101945 [details] [diff] [review]
Checks css visibility in IsRangeVisible()

r=kyle. same comment as for bug 172656.

Comment 13

[Alec Flett]

Comment on attachment 101945 [details] [diff] [review]
Checks css visibility in IsRangeVisible()

sr=alecf

Comment 14

[Aaron Leventhal]

Forgot to mark this fixed, it was checked in a while ago.

Comment 15

[sairuh (rarely reading bugmail)]

the attached testcase is the wrong mime, but the test url works. vrfy'd with
2002.11.19 comm trunk bits.