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)

64 Branch
x86_64
macOS
defect

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
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
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
Attached file reduced test
Here's a test based on comment 0.  Brian, what's the right behavior here?
Flags: needinfo?(bbirtles)
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
(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[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)
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)

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

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.

Attachment

General

Creator:
Created:
Updated:
Size: