Closed Bug 1495392 Opened Last year Closed 3 months ago
Unable to remove stacking context created by transform
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
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Could you attach an HTML test-case to the bug? Thanks!
I've attached a real world example to the original report.
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
Here's a test based on comment 0. Brian, what's the right behavior here?
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?
(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.
(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.
(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.
FWIW the comment 3 site's openAndRemoveTransform animation is animation-fill-mode:none.
For the test case in comment 4, the behavior seems correct. As per CSS animations: "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.  https://drafts.csswg.org/css-animations/#animations
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.
Webcompat Priority: --- → ?
Priority: -- → P3
Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.