223607 - img:hover with -moz-opacity in userContent.css kills HREFs on images

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Joe McCabe]

User-Agent:       Mozilla/5.0
Build Identifier: 2003102413

When using this

/* Change display of images when hovered */
img:hover, a:hover > img { 
  -moz-opacity: .9;
}

in userContent.css the HREFs on images are not honored. Click away on the image,
the link is not followed.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Mats Palmgren (inactive)]

WFM, 2003-10-23-05 trunk Linux.

Do you see the same problem if you make a small testcase with that style and
not use userContent.css at all?

Comment 2

[Boris Zbarsky [:bzbarsky]]

What windomanager are you using?  And are you using a gtk2 or gtk1 build?  I bet
this is bug 102578

Comment 3

[Joe McCabe]

Mats: Haven't tried to reduce the test case any further. I strongly suspect that
that CSS applied directly to a web page would produce the same results though.

Boris: Reading through 102578 makes me want to agree with you - this looks like
it's probably the same problem.

My environment is:

1) Built from tip with Red Hat 9
2) Built with gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
3) Build steps followe are very simple:

MOZILLA_OFFICIAL=1 ; export MOZILLA_OFFICIAL
BUILD_OFFICIAL=1 ; export BUILD_OFFICIAL
MOZ_INTERNAL_LIBART_LGPL=1 ; export MOZ_INTERNAL_LIBART_LGPL

gmake -f client.mk checkout

./configure --enable-xft --disable-tests --disable-debug --enable-optimize
--without-system-nspr --without-system-zlib --without-system-jpeg
--without-system-png --without-system-mng --enable-crypto --enable-calendar

gmake -f client.mk build

4) Using Gnome with Sawfish

Comment 4

[Boris Zbarsky [:bzbarsky]]

Sounds like retesting after bug 102578 is marked fixed would be a good idea... ;)  

My personal bet on the sequence of events is that the click causes mouseout,
which turns off the hover, which causes destruction of the layout object the
click was on... then we unwind back off the event dispatch to actually trigger
the link, but the layout object is gone so we don't know what got clicked.

Comment 5

[Hixie (not reading bugmail)]

If that's the case, shouldn't we be taking stick of what DOM Node to fire the
event on before we risk losing track of that information? :-)

Comment 6

[Joe McCabe]

As soon as I see a checking for 102578 I'mm rebuild and see if the behavior is
gone (I see a patch had been r= and sr=, so I don't imagine it'll take long to
land in the trunk).

Comment 7

[Boris Zbarsky [:bzbarsky]]

Once the tree reopens for 1.6b...

Comment 8

[Joe McCabe]

Just for larks I've directly applied the GTK2 patch from 102578:

http://bugzilla.mozilla.org/attachment.cgi?id=132413&action=view

Rebuilt, re-enabled the user-content hover pref. Clicks still aren't working
(but keyboard activiation of the HREF does work).

Hmm. No time right now, but later today I'll look into whether I need to also
apply the xlib and GTK patches.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Joe, you need the regular gtk patch, since you are not using a gtk2 build.

It's odd that you could apply the gtk2 patch -- that's been checked into the
tree for a while now...

Comment 10

[Joe McCabe]

Ok - Just to make sure I'm not doing something funky I blew away the
widget/src/gtk and widget/src/gtk2 directories, refreshed them from CVs, then
applied the GTK patch from here:

http://bugzilla.mozilla.org/attachment.cgi?id=128909&action=view

New build, same broken behavior.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Joe, are you seeing the broken behavior in bug 102578 on the testcases in that
bug?  Do the patches there fix it for you?  Parhaps the patches for gtk1 and
xlib don't quite work.... 

Comment 12

[Joe McCabe]

Just for the sake of completeness I've applied the GTK and xlib patches (again),
and built. I've hit the test case in 102578 (second comment). If I understand
that test case currently, I still see their broken behavior (e.g. mouse over
square, square goes black; mouse out of square, square goes white; click on
square, square goes white and page background goes blue, then white - I assume
expected behavior is that the square should not go white until my mouse leaves
the square).

Next, later tonight, is to blow away my build tree and start from scratch, Make
sure that there's no lingering .os that aren't getting blown away by the build
process.

Comment 13

[Joe McCabe]

Alrighty then. I've rebuilt after changing

gmake -f client.mk checkout 

to

gmake -f client.mk checkout clean

I've verified that the gtk and Xlib patches are both applied. I've built. I
still see clicks on IMGs with hrefs not working (and losing their "hover"
attribute), and the test case in 102578 continues to exhibit what I expect is
the broken behavior (the box turns white on click, in addition to the page
background turning blue).

Sooo ... Unless I'm doing something really wrong in my build, the GTK/Xlib fix
for 102578 doesn't fix the problem I've reported, nor does it appear to fix the
problem reported in 102578 as reported.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Yeah, that's what it sounds like.  See bug 102578 comment 113.

Comment 15

[Joe McCabe]

Quick update - Disable Gnome 2, Enable KDE 3.1. Everything now works as expected
in Mozilla. HREFs on images are working, the test case from 102578 is working, etc.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Right.  Notice that bug 102578 is window-manager-dependent....

This does make it more likely that this is the same bug, though.  ;)

Comment 17

[Joe McCabe]

Yeah, I know 102578 is WM dependent. That's why I did this liitle test - to make
certain that we really are seeing the same thing. I figured this would come in
handy when/if people from 102578 ask if this is really the same issue.

Comment 18

[Joe McCabe]

Here's another interesting twist on this bug:

Change 

  -moz-opacity: .9;

to

  -moz-opacity: 1;

and the bad behavior goes away (though the test case in 102578 is still broken,
despite the GTK patch still being present).

Comment 19

[Boris Zbarsky [:bzbarsky]]

Yeah, if the opacity does not change then the layout object teardown I mentioned
in comment 4 does not happen...

Comment 20

[Joe McCabe]

Applied the reworked GTK patch from 102578. The test case in 102578 now works
correctly, as does clicking on image HREF.

Looks like different symptoms of the same bug.

This bug (223607) can probably be resolved as a duplicate of 102578, and the GTK
fix in 102578 can probably be checked in once it has r= and sr=.

Comment 21

[Joe McCabe]

gtk build after checkin for 102578 (2003111709) makes things behave as expect.

This issue seems resolved by 102578.

Marking Resolved, Fixed.