Closed Bug 1256980 Opened 8 years ago Closed 4 years ago

"z-index" has an effect on transformed content in Firefox, but not in Edge/Safari/Chrome

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla80
Project Flags:
Webcompat Priority P2
Tracking Flags:
Tracking Status
firefox48 --- wontfix
firefox80 --- fixed

People

(Reporter: dholbert, Assigned: emilio)

References

(Regressed 1 open bug)

Details

(Whiteboard: [webcompat][layout:backlog], [wptsync upstream])

Attachments

(3 files, 1 obsolete file)

testcase 1
458 bytes, text/html
Details
test-case2.html
314 bytes, text/html
Details
Bug 1256980 - Make z-index only apply to positioned and grid / flex item frames. r=miko!,#layout-reviewers!
47 bytes, text/x-phabricator-request
Details | Review
Attached file testcase 1 — 
STR:
 1. Load attached testcase.


[I'll phrase ACTUAL vs EXPECTED from the perspective of compatibility, i.e. matching other browsers. Not sure what the spec requires.]

ACTUAL RESULTS:
No lime is visible. (The "z-index" is honored, which pushes the lime element behind its wrapper since the value is negative.)

EXPECTED RESULTS:
Lime should be visible. (The "z-index" should be ignored; at least, it is in other browsers.)


Firefox gives ACTUAL RESULTS.
Webkit, Blink, & Edge give EXPECTED RESULTS.


(At first I thought this was a question of whether a transformed element forms a stacking context or not, but Chrome does seem to agree with us that the transformed element does form a stacking context, as demonstrated by https://jsfiddle.net/q57ju0fk/7/ .  That jsfiddle shows that a positioned element with a positive z-index inside of a transformed ancestor will get contained to the transformed ancestor's stacking-context, and hence can be covered up by the positioned "cover" element.

So really, this seems to just be a case of whether or not "z-index" affects the stacking order of transformed elements, I think.)
This bug is responsible for content not being clickable in this webcompat issue, BTW:
  https://github.com/webcompat/web-bugs/issues/2280

(In that issue, some high-level ancestor is both transformed & has a negative z-index value [not sure why the web developer chose to do that, but whatever].  In Firefox, we honor the negative z-index, which means clicks on links/widgets end up being absorbed by the <body>, since the <body> is in front. So, the site is completely unclickable. In other browsers, the z-index seems to have no effect, so the content is clickable.)
See Also: → https://github.com/webcompat/web-bugs/issues/2280
The key piece of spec text here seems to be that "z-index" is only supposed to apply to "positioned" elements.

> 'z-index'
>[...]
>    Applies to:  	positioned elements
https://drafts.csswg.org/css2/visuren.html#z-index

"Appendix E. Elaborate description of Stacking Contexts" also reemphasizes this by explicitly using the word "positioned" when listing the stacking levels that involve z-index:
> 3. Stacking contexts formed by positioned descendants with negative z-indices
> [...]
> 8. All positioned descendants with 'z-index: auto' or 'z-index: 0'
> [...]
> 9. Stacking contexts formed by positioned descendants with z-indices greater than or equal to 1
https://drafts.csswg.org/css2/zindex.html#painting-order

So the key question here is, does a transform element count as "positioned"?  I think no, because section 9.3.2 says:
> An element is said to be positioned if its 'position'
> property has a value other than 'static'. Positioned
> elements generate positioned boxes
https://drafts.csswg.org/css2/visuren.html#position-props

The CSS Transforms spec *could* say that transformed elements also count as positioned, but it does not. It says they form "both a stacking context and a containing block", but it doesn't say they're positioned. https://drafts.csswg.org/css-transforms/#transform-property

So I think we're in the wrong here.
I came to the same conclusion investigating https://crbug.com/613976
Seems like we'd need to fix both ZIndexForFrame in nsDisplayList.cpp and nsIFrame::BuildDisplayListForChild.
... and nsContainerFrame::SyncFrameViewProperties.
(We should perhaps also audit whether there were any other cases in https://hg.mozilla.org/mozilla-central/rev/b9951cca6d1f that wanted IsPositioned, and probably make IsPositioned exist again...)
Probably another instance of this issue on webcompat
See Also: → https://webcompat.com/issues/3616
Whiteboard: [webcompat]
Attached file test-case2.html — 
Today I encountered yet another google website using transform and z-index:-5, which makes links unclickable on Firefox. Simplified test-case attached.
which web site?
Flags: needinfo?(kchen)
https://www.google.com/about/careers/students/guide-to-technical-development.html

It has similar css style applied as https://github.com/webcompat/web-bugs/issues/2280 so I guess it is some template used by google.
Flags: needinfo?(kchen)
ok same site but different page. Thanks.
Google has localized versions of their properties so the domain can change but often the content is the same.
This just bit Google's enterprise partner page as well: https://enterprise.google.com/intl/en_us/partners/become-a-partner/

I wonder why they even use negative z-indices like this? It might be worth reaching out to see if they're working around one bug only to trigger another.
Flags: webcompat?
See Also: → https://webcompat.com/issues/16051

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Webcompat Priority: ? → P2
Flags: webcompat?
Blocks: 1571896
See Also: → 1616361
Whiteboard: [webcompat] → [webcompat][layout:backlog]

I just pushed a try with the change what :mattwoodrow suggested in bug 1506215 comment 4.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=39b50fd0edf25cae1b7d8e6d16cbb05180a9f21b

The results noticed me that there are test cases which is testing that z-index on flex items and grid items should be applied even if it's not a positioned element. https://drafts.csswg.org/css-flexbox-1/#painting and https://drafts.csswg.org/css-grid/#z-order

Pushed another try with the modifications.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6b7172216e74d452158eff1e424a7b94de33f735

Severity: normal → S3
Priority: -- → P2
Assignee: nobody → emilio
Status: NEW → ASSIGNED
Attachment #9160092 - Attachment is obsolete: true
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8042b7b36943
Make z-index only apply to positioned and grid / flex item frames. r=miko,hiro
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/24406 for changes under testing/web-platform/tests
Whiteboard: [webcompat][layout:backlog] → [webcompat][layout:backlog], [wptsync upstream]
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

https://hg.mozilla.org/mozilla-central/rev/8042b7b36943

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox80: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla80
Upstream PR merged by moz-wptsync-bot
status-firefox48: affected → wontfix
Flags: in-testsuite+
Regressions: 1663819
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: