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 :).
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
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.
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>.
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.
"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.
I really think this is INVALID.
(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
(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?
> 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.
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.