79594 - :hover doesn't work on text originally invisible as overflow

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Chris Lea]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505
BuildID:    2001050515

HREF's which have been affected with a:hover AND which are not initally visible
when the page loads because the link is overflowed out of a DIV do not exhibit
the correct :hover attribute. Specifically, this happens on a site that uses
DHTML "scrolling" to show text that's not initially visible.

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.chrislea.com and click on the enter graphic. This will pop
up a new window.

2. On the first page you see, use the down arrow just to the left of the top
part of the text to scroll down. Keep scrolling until you see a link which you
couldn't see when the page first loaded (links are bold.)


3. Put your mouse over the link.

Actual Results:  The link does not underline when the mouse is hovering on it.

Expected Results:  The link should underline when the mouse is hovering on it.

This works for any link which you can see when the page loads initially. Meaning
that the underline appears for such a link. I see the same behaviour in Linux
2.2.19 with the Mozilla 0.9 release.

Comment 1

[Boris Zbarsky [:bzbarsky]]

sounds like it could be a compositor issue...  Are we maybe not repainting those
because we think they are still invisible?  I see this on Linux build
2001-05-08-08, by the way.

Comment 2

[Chris Lea]

Not sure if this matters / helps, but I have another page at
http://www.chrislea.com/devel/ which has links originally hidden but which
exhibits the CORRECT behaviour. For example, scroll around on the box in the
lower left corner.

On this page, the divs are set up with overflow=auto and the text and links are
put into the divs with innerHTML. On the page which DOESN'T work, I believe the
div "scrolls" around by moving the div itself.

If I can help out by decomposing these in some way please let me know.

Comment 3

[joki (gone)]

Selection also doesn't work in the originally clipped area.  I don't believe 
event targetting is at fault since the links work, the cursor updates correctly, 
and a selection which is begun inside the non-working area and dragged up into 
the originally visible and working area will still display properly in that 
upper area.  So who gets this one?  It seems most likely we're seeing style 
updates getting filtered out due to a mistaken notion that the area in question 
isn't visible.

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I am guessing David Baron, reassigning. If this is what I think it is, we are
not properly updating the state in element.

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: somewhat simplified testcase

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: simpler testcase

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Mousing around in the last testcase in viewer with Event Target Debugging makes
this seem like an invalidation problem.

Comment 8

[Madhur Bhatia]

QA contact updated

Comment 9

[Michael van Ouwerkerk]

I think I've seen the same thing happen in a dhtml scroller that manipulates 
opacity as a transition effect. The opacity of the overflowed section is not 
updated. You can see an example here:
http://e-syed.net/skriptlab/pageslidefade/pageslidefade.htm

You can scroll down a bit with the arrows, then click one of the links (I, II, 
III) to fade out and get a new layer. Only the section that was not originally 
overflowed gets faded.

build info:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011

There are more problems with clipping and overflow, some people have suggested 
it may affect performance a great deal, in bug 21762:
http://bugzilla.mozilla.org/show_bug.cgi?id=21762

Thanks ppl

Comment 10

[Chris Lea]

Confirmed that I see Michael van Ouwerkerk's bug on the 0.9.5 build running
Linux. Looks like the exact same problem to me. I can probably point to a half
dozen other examples that highlight the problem if they would be useful.

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

*** Bug 116597 has been marked as a duplicate of this bug. ***

Comment 12

[David Pedowitz]

Attachment: Javascript rollover test

This proves that JavaScript rollovers are also affected when moved into visible
area

Comment 13

[David Pedowitz]

Actually, the above testcase may be a new bug all together :(

Comment 14

[David Pedowitz]

Created new bug for last few posts, sorry for the clutter!

http://bugzilla.mozilla.org/show_bug.cgi?id=122265

Comment 15

[Chris Lea]

Umm... not sure what happened, but everything in the test cases is working for
me now using rc1 under Linux.

Comment 16

[David Pedowitz]

Me too!!! WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1)
Gecko/20020417

Comment 17

[Asa Dotzler [:asa]]

worksforme with windows Mozilla 2004020308