52766 - Complex :hover behaviors do not work consistently

Status: RESOLVED WORKSFORME

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

Description

[joki (gone)]

This bug is being carried over from 5693 which is almost completely fixed with 
this exception (so far).  The :hover rules on the site in question work in some 
locations but not others.  Getting reduced test cases for the non-working areas 
would be a big help here.

Comment 1

[joki (gone)]

This won't make it into this release

Comment 2

[Loco]

Updating QA Contact.

Comment 3

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 4

[James Green]

OK this bug needs to be more specific. Talking with glazou on this matter, and I
came up with a reduced testcase based on the code which doesn't work properly on
the site http://linuxnewbie.com/.

Nominating for mozilla0.9 and adding css2 keyword. CCing self, testcase to follow.

Comment 5

[James Green]

Attachment: Testcase showing a div:hover losing it's style when hovering in it's content

Comment 6

[James Green]

The attached testcase shows a div within a table. The table is there to present
the black border indicating the boundaries for easier testing only.

The table contains a div. The div is defined for grey content. It's :hover event
it defined for grey text. Move your mouse over the div *box* and see the text go
black. Now move the mouse over the *content* of the div (that it, not in any
whitespace area at the end of the text line), and the text goes grey again.

The text should remain black while hovering over the content of the div. It
should not go grey until we return outside of the div's box.

Comment 7

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

This is what the patch on bug 5693 (to re-enable hierarchical :hover) should
fix, I think.  However, this bug was originally about other issues (before
hierarchical :hover was disabled).

However, we can't get the CSS WG to agree on this (one member thinks this is the
correct behavior).

Comment 8

[phule]

Attachment: Another example of improper behavior of :hover

Comment 9

[phule]

Attachment: What needed to be done to the CSS from csstest01 to get it to work in Mozilla (0.8.1)

Comment 10

[phule]

I've attached 2 HTML files.  csstest01 shows the improper behavior of A:hover, 
and csstest02 provides the change in the CSS that gets it to work in mozilla. 
The only change made was that A:hover was moved to the very bottom of CSS 
definition.

Comment 11

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

The two testcases above demonstrate correct behavior.  (The weight, origin, and
specificity of the rules are the same, so the order is relevant.)  Please don't
clutter bugs with other issues.  Even if that were a bug, it would be a separate
bug and should be filed as a separate bug report rather than cluttering up this
one and making it confusing to anyone who reads it.

Please do NOT discuss any issues relating to those testcases on this bug report.

Comment 12

[Andrew Thompson]

Attachment: Test showing very odd hover behaviour from <img> inside <a>

Comment 13

[Andrew Thompson]

I believe I'm also seeing problems relating to odd :hover inconsistencies.

In the example I attached, two images are given borders, the colour is changed
in img:hover. The second image is inside an <a> tag, the first is not. The first
behaves what I consider to be correctly, the second doesn't.

If this is a heirarchical hover problem, then its odd one as I understand it,
because its the *inner* element (the img) that's being styled not the outer one.

I have more complex pages where the :hover effect occurs, but it happens in a
weird way, eg, it draws the border, but it draws it as if the image had 0 height
(but the correct width). (screenshot coming)

Comment 14

[Andrew Thompson]

Attachment: Shows hover as if image was of 0 height...

Comment 15

[Andrew Thompson]

This comes from this css and html

img {  border: thin transparent solid; }
img:hover { border: tthinhick #FF0099 solid; }

<p><a 	href="VendingMachines.jpg" title="Click for a bigger version of this image">
<img alt="Vending machines outside Dean's place" 
	src="lowres/colour/VendingMachinesLQC.jpg" >
</a>
</p>

Comment 16

[James Green]

lordpixel, neither of these are bugs. The first has style rules that only apply
to the img elements, the second is because the box model for p has a line-height
set, thus you'll get a border at the bottom of the image, which is a very common
mistake - to fix you need to make the img a block-level element (I think).

Comment 17

[Andrew Thompson]

Hmmm, well, if you're *sure* but I don't get it:

>The first has style rules that only apply to the img elements, 

But there are 2 img elements, one reacts to hover the other doesn't. Does placing 
the img inside another inline element (the <a>) preclude it from having hover 
effects? Why? There's still an img there, is there nothing to draw a border 
around? Why does one work and the other not?

>The second is because the box model for p has a line-height
>set, thus you'll get a border at the bottom of the image, which is a very common
>mistake - to fix you need to make the img a block-level element (I think).

Hmmm, I have a feeling this leads into a *huge* discussion about the definition 
of line height in a box which only contains images, as on www-style per nauseum. 
Since I'm way out of my depth there I'm reduced to pointing out that behaviour is 
counter-intuitive and practially useless. Making the img a display:block is 
useless as it limits me to one image per line, display:run-in not being 
implemented in Mozilla. Sigh :( 

Apologies if all I've done is spam this bug, but I *really* can't see why the 
first case is valid.

Comment 18

[Madhur Bhatia]

QA contact updated

Comment 19

[neil]

I think all the problems discussed in this bug either were invalid at the start, 
(forgivable, IMHO, as there are parts of CSS that aren't obvious) or have been
resolved (the heirarchical nature of :hover being the bug).  

I think the bug should be resolved either fixed or invalid.

Comment 20

[Pham]

.

Comment 21

[louis bennett]

based on the original test case of this bug and subsequent discussion herein,
marking FIXED.

Comment 22

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

should be worksforme, not fixed