Regression in FF3.0b2: Links no longer able to capture click events through transparent ancestor elements

RESOLVED INVALID

Status

()

Core
Event Handling
P3
normal
RESOLVED INVALID
11 years ago
10 years ago

People

(Reporter: Michael Landis, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
regression
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

In Firefox 2, links that are underneath transparent ancestor elements are clickable. This is no longer the case in Firefox 3. The test case at http://michael4css.info/experiments/tabs.html illustrates this. While searching for similar bugs I came across bug 102695 which suggests looking for an overall solution for handling clicking through transparent elements, but I am filing this separately as it appears to be a regression rather than another test case for that bug.

Reproducible: Always

Steps to Reproduce:
1. Create a positioned element with a positive z-index
2. Create a relatively positioned child link within that element with a negative z-index
3. Try to click the link
Actual Results:  
The link is no longer clickable. The cursor does not change to a pointer while over the transparent area masking element.

Expected Results:  
The link should still be clickable, as it is in Firefox 2
Regression window is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-01-25+16%3A00&maxdate=2006-01-26+10%3A00
That seems to point to bug 317375. If not correct or a dupe, please undo the dependency :).
Blocks: 317375
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: unspecified → Trunk
I think the problem here is that the <li> is on top of <span>, so it gets the click.

I think what we're doing is entirely consistent with CSS 2.1 appendix E: http://www.w3.org/TR/CSS21/zindex.html
Any disagreement?
(Reporter)

Comment 3

11 years ago
With regards to painting order, I agree completely -- it is being painted properly, per spec. (On the site I work on, that confused me for a while, as FF3 now properly paints negative z-index borders and backgrounds atop the parent border/background, rather than painting it underneath the way most browsers had done.)

Unfortunately, all of the CSS specs state that they don't determine how elements receive the :hover or :active pseudo-classes, which is about as close as CSS gets to this link behavior.

Given how little the specifications (DOM/HTML/CSS) say about this matter, and the back-and-forth discussions in bug 102695, I'd hesitate to ask about finding the "right" answer (although I also like the idea presented in bug 380573). But changing the :hover/:active behavior from FF2 to FF3 without direction from the specs is a little disconcerting, not to mention site-breaking.
(Reporter)

Comment 4

11 years ago
Sorry for the extra comment, but I updated http://michael4css.info/experiments/tabs.html to add :hover/:active styles to the tabs, and also removed the red border on the UL to reduce the test case to transparent elements (to avoid leaving the question open about transparent elements versus transparent elements with visible borders).
We're just making event targeting consistent with painting. So the mouse isn't targeting the <span> because the <li>'s (invisible) background is on top of the <span>; the mouse is only registering as over the <li>.
(Reporter)

Comment 6

11 years ago
That makes sense, in terms of explaining what is happening, but I am still confused as to how this benefits the users of Firefox or web site developers, or how this makes the browser more conformant to web standards. It still feels like a regression, or at least a negative consequence of the refactoring done in 317375.

Perhaps we need input from others about this? It seems that we have irreconcilable viewpoints on this matter.
> how this benefits the users of Firefox or web site developers,
> or how this makes the browser more conformant to web standards.

We've made both rendering and event targeting consistent with CSS 2.1 Appendix E. That's all.
(Reporter)

Comment 8

11 years ago
"That's all" suggests that it has a superficial impact. I'm saying that the impact isn't superficial. Applying Appendix E to the presentation is proper. I fail to see why Appendix E should apply to event targeting, especially in a way that reduces the abilities of the browser.
Flags: blocking1.9?
I really think this is INVALID.

Comment 10

11 years ago
(In reply to comment #8)
> "That's all" suggests that it has a superficial impact. I'm saying that the
> impact isn't superficial. Applying Appendix E to the presentation is proper. I
> fail to see why Appendix E should apply to event targeting, especially in a way
> that reduces the abilities of the browser.
> 

Can you give a quick explanation of why you need the existing behavior?  Is there a workaround?
+'ing with P3 priority.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
(Reporter)

Comment 12

11 years ago
(In reply to comment #10)
> Can you give a quick explanation of why you need the existing behavior?  Is
> there a workaround?

Sure! The current behavior allows us to place the currently highlighted tab in front of the content area and the other tabs behind the content area. The real life scenario in question is at http://www.americanfunds.com/about/different/focus.htm.

The reason for doing this is to allow the highlighted tab to overlap the black line that surrounds the content area, so that it appears to be part of the content area, while the other tabs do not occlude the content area. You can see the desired presentation and behavior in Firefox 2.

Now that Firefox 3 properly obeys Appendix E in presentation, I will need to change the structure so that the list is a sibling of the content area, rather than a child. This appears to recreate the in-front/behind look of the tabs. However I don't see a way to circumvent the behavior issue and maintain this presentation.
Created attachment 295312 [details]
modified version of the testcase

Here's your testcase with a few small modifications:
-- ".container div" is relatively positioned with z-index:1
-- "span a" has no z-index, putting it behind the div
-- "strong a" has z-index 2, putting it in front of the div
It looks exactly the same as before and seems to work fine. Is there a problem with this approach?
(Reporter)

Comment 14

11 years ago
> It looks exactly the same as before and seems to work fine. Is there a problem
> with this approach?

This looks like it'll do nicely! Thank you for working through what I couldn't see. I'm still not certain that the new behavior shouldn't be considered a regression, but at least this resolves my particular concern.

Comment 15

10 years ago
reopen if you disagree
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.