Closed Bug 1179288 Opened 10 years ago Closed 9 years ago

change position:fixed so it always creates a stacking context

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla44
Tracking Flags:
Tracking Status
firefox42 --- affected
firefox43 --- affected
firefox44 --- fixed

People

(Reporter: dbaron, Assigned: roc)

References

Details

(Keywords: dev-doc-complete, site-compat)

Attachments

(1 file)

MozReview Request: Bug 1179288. Make position:fixed induce a stacking context. r=heycam
40 bytes, text/x-review-board-request
heycam
: review+
Details
The CSS WG resolved on 2015-07-01 to change position:fixed so that it always creates a true stacking context, for Web compat reasons. (This is needed since Safari and Chrome have worked that way for years.)
... note that I believe this includes when it's not actually "fixed" because it's inside something with 'transform'
Assignee: nobody → roc
(In reply to David Baron [:dbaron] ⏰UTC+2 (busy Aug. 8-Aug. 30) from comment #1) > ... note that I believe this includes when it's not actually "fixed" because > it's inside something with 'transform' What is this rule?
(In reply to Cameron McCormack (:heycam) from comment #5) > (In reply to David Baron [:dbaron] ⏰UTC+2 (busy Aug. 8-Aug. 30) from comment > #1) > > ... note that I believe this includes when it's not actually "fixed" because > > it's inside something with 'transform' > > What is this rule? A number of properties (transform, ) specify that non-default values cause the element to create a containing block for position:fixed elements. See nsStyleDisplay::IsFixedPosContainingBlock.
But does that affect whether non-position:fixed descendants need to create a stacking context? (I was reading into your comment 1 that to fix this bug we need to check something other than the value of position, but I'm not sure we do. Maybe I am misinterpreting?)
Comment on attachment 8648609 [details] MozReview Request: Bug 1179288. Make position:fixed induce a stacking context. r=heycam https://reviewboard.mozilla.org/r/16255/#review14615 If there is another case that needs handling we can do it in another patch.
Attachment #8648609 - Flags: review?(cam) → review+
url: https://hg.mozilla.org/integration/mozilla-inbound/rev/89a5b5c8ce17eaefdea8178171567ee309bbf447 changeset: 89a5b5c8ce17eaefdea8178171567ee309bbf447 user: Robert O'Callahan <robert@ocallahan.org> date: Mon Aug 17 11:02:54 2015 +1200 description: Bug 1179288. Make position:fixed induce a stacking context. r=heycam
https://hg.mozilla.org/mozilla-central/rev/89a5b5c8ce17
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox43: --- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Depends on: 1199443
Depends on: 1201078
Depends on: 1203891
roc, I guess we'd probably better backout this bug on 43 for regressions like bug 1201078, and reland it for 44 after the merge day. It seems top layer (bug 1126230) won't be able to catch 43 because of bug 1069192, which I don't think could land in this week.
Flags: needinfo?(roc)
OK.
Flags: needinfo?(roc)
Actually I think I'll back this out of Aurora after the uplift has occurred from Nightly to Aurora, rather than back it out on Nightly now and reland it after the uplift.
Backed out of Aurora in https://hg.mozilla.org/releases/mozilla-aurora/rev/2c8e89fa7719 Adjusting the status flags as I think they should be. Feel free to correct them if I thought wrong.
status-firefox43: fixed → affected
status-firefox44: --- → fixed
Target Milestone: mozilla43 → mozilla44
The site compatibility doc is up: https://www.fxsitecompat.com/en-US/docs/2015/css-position-fixed-now-always-creates-stacking-context/ My Firefox app was broken with this change ;-)
Keywords: site-compat
Depends on: 1261121
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: