Closed
Bug 1495392
Opened 6 years ago
Closed 5 years ago
Unable to remove stacking context created by transform
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
RESOLVED
INVALID
Webcompat Priority | ? |
People
(Reporter: inkjetlakes, Unassigned)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3559.6 Safari/537.36 Steps to reproduce: Setting a transform on an element will create a new stacking context, however removing this transform later (eg: by setting transform to either none or initial via an animation or new class) will not reset this stacking context. As a result, once added it's impossible to remove this stacking context, for example to position a child relative to outer parent. In Chrome, setting transform to none correctly resets stacking context (see comparison photo attached) Steps to reproduce: 1) Create a <ul> element, with a number of <li> elements. Set position of this <ul> to relative 2) Transform this <li> element in some way 3) Add a second <ul> element as a child of this <li> element 4) Position second <ul> absolutely, with top, left, right, and bottom properties all set to 0 5) Add transform: none to <li> element Actual results: Regardless of whether transform is set, the second <ul> is positioned relative to the <li> element. Expected results: When transform is set, the second <ul> should be positioned relative to the <li>'s stacking context When transform has been set to none, the second <ul> should be positioned relative to the parent <ul>'s stacking context
Reporter | ||
Updated•6 years ago
|
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Reporter | ||
Updated•6 years ago
|
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Comment 1•6 years ago
|
||
Could you attach an HTML test-case to the bug? Thanks!
Reporter | ||
Comment 2•6 years ago
|
||
I've attached a real world example to the original report.
Reporter | ||
Comment 3•6 years ago
|
||
Oh no I haven't. Real world example: http://proxima.dev.theblackeyeproject.co.uk 1) Reduce window width to small until hamburger menu appears 2) Click on hamburger 3) Select "Sectors", about halfway down list 4) Submenu will open in a way that demonstrates the bug
Comment 4•6 years ago
|
||
Here's a test based on comment 0. Brian, what's the right behavior here?
Flags: needinfo?(bbirtles)
Comment 5•6 years ago
|
||
I don't understand why HasAnimationOfTransform is included in IsCSSTransformed: https://searchfox.org/mozilla-central/rev/eac6295c397133b7346822ad31867197e30d7e94/layout/generic/nsFrame.cpp#1545 Looks like it comes from bug 1278136, and looks intentional per that. But what I really don't know is why this isn't accounted for in IsAbsPosContainingBlock... Shouldn't ReferenceFrame and such agree with IsAbsPosContainingBlock?
Blocks: 1278136
Comment 6•6 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5) > I don't understand why HasAnimationOfTransform is included in > IsCSSTransformed: > > > https://searchfox.org/mozilla-central/rev/ > eac6295c397133b7346822ad31867197e30d7e94/layout/generic/nsFrame.cpp#1545 > > Looks like it comes from bug 1278136, and looks intentional per that. Yes, we need to create a stacking context even if the transform animation is in delay state (and endDelay of course) or the animation is from 'transform:none' to 'transform:none'. There might be a better place to do that though, I am not sure. > But what I really don't know is why this isn't accounted for in > IsAbsPosContainingBlock... Shouldn't ReferenceFrame and such agree with > IsAbsPosContainingBlock? I have no idea about this. (In reply to Cameron McCormack (:heycam) (away 6 Nov) from comment #4) > Created attachment 9021710 [details] > reduced test > > Here's a test based on comment 0. Brian, what's the right behavior here? The transform animation in question is fill:forwards unfortunately, we need to reap it in bug 1253476? Or it might be the right behavior though.
Comment 7•6 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #6) > The transform animation in question is fill:forwards unfortunately, we need > to reap it in bug 1253476? Or it might be the right behavior though. Ah, I meant to remove the "forwards" there. Same issue though.
Comment 8•6 years ago
|
||
(In reply to Cameron McCormack (:heycam) (away 6 Nov) from comment #7) > Ah, I meant to remove the "forwards" there. Same issue though. Oh, my mistake; removing the forwards doesn't exhibit the problem.
Comment 9•6 years ago
|
||
FWIW the comment 3 site's openAndRemoveTransform animation is animation-fill-mode:none.
Comment 10•6 years ago
|
||
For the test case in comment 4, the behavior seems correct. As per CSS animations[1]: "While an animation is applied but has not finished, or has finished but has an animation-fill-mode of forwards or both, the user agent must act as if the will-change property ([css-will-change-1]) on the element additionally includes all the properties animated by the animation." I believe Chrome has yet to implement this, however. [1] https://drafts.csswg.org/css-animations/#animations
Flags: needinfo?(bbirtles)
Comment 11•6 years ago
|
||
Cameron, I can see fill:forwards for openAndRemoveTransform and also for openSubMenu (it's on a parent element) in the site. If I am seeing correct results, I think this is a Chrome bug not for us.
Flags: needinfo?(cam)
Comment 12•5 years ago
|
||
Brian: Should we close this and file a Chrome bug per comment 10 and comment 11?
(Flagging webcompat just in case.)
Webcompat Priority: --- → ?
Flags: needinfo?(bbirtles)
Priority: -- → P3
Comment 13•5 years ago
|
||
Looks like there is already a Chrome bug for this: https://bugs.chromium.org/p/chromium/issues/detail?id=903946
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(cam)
Flags: needinfo?(bbirtles)
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•