Sp-dev-docs: Canvas-slideUpIn not removed after animation - "breaks" position: fixed CSS property

[semopz]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

HTML elements rendered inside an SPFx webpart with a CSS position value of fixed should be position relative to the viewport.

Observed Behavior

HTML elements with a position property value of fixed are positioned relative to the webpart's parent canvas control

Steps to Reproduce

1. Create an SPFX webpart (^1.9)
2. Add an HTML element and set its position to fixed via CSS/style
3. Observe position of element
4. Go in F12 tools and remove the Canvas-slideUpIn from your webpart's immediate ancestor
5. Fixed position element should now be positioned relative to viewport instead of parent element

Suggested Fix

Once the webpart is rendered and the slide animation is finished, the Canvas-slideUpIn class should be removed automatically as its CSS contains a transform. Although the animation is no longer active (it only happens once per page load), an undesirable side effect is persisted and the element is forced to become a containing block (think iframe) so postion: fixed stops acting the way a dev might expect.

Further information from W3C

For elements whose layout is governed by the CSS box model, any value other than none for the transform property also causes the element to establish a containing block for all descendants. Its padding box will be used to layout for all of its absolute-position descendants, fixed-position descendants, and descendant fixed background attachments.

W3C example

Workaround 1 (supported)

Use a single part app page. At time of writing, there is no such animation on single app part pages but of course you forgo the use of 1st party web parts.

Workaround 2 (unsupported)

Overwrite CSS of parent element to unset the transform properties or remove the Canvas-slideUpIn class using DOM manipulation
https://github.com/SharePoint/sp-dev-docs/issues/3218#issuecomment-457364664

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[andrewconnell]

@StfBauer you'd have more insight into possible CSS issues than I...

[StfBauer]

Don't use position fixed. The value you are looking for is position: relative.
Then the position is relative to the viewport while fixed position it fixed.

Your fixed positioned element will appear somewhere on the page defined by the values of top, bottom, right, left. Fixed but not relative.

Definition position fixed: MDN

The element is removed from the normal document flow, and no space is created for the element in the page layout. It is positioned relative to the initial containing block established by the viewport, except when one of its ancestors has a transform, perspective, or filter property set to something other than none (see the CSS Transforms Spec), in which case that ancestor behaves as the containing block. (Note that there are browser inconsistencies with perspective and filter contributing to containing block formation.) Its final position is determined by the values of top, right, bottom, and left.

Can you provide an example that shows what you try to accomplish? This would help for a better understanding. I tested your scenario just by positioning the elements and in case of the fixed it even hasn't shown up on the page. Plus it is not really supported to break with a fixed positioned element out of the web part context instead you could use an application customizer as an extension.

[semopz]

@StfBauer
I've provided an example (instructions in the example) of a symptom but please note that this is just an example to demonstrate what I believe is an undesired side effect.
https://codesandbox.io/s/react-toastify-or3pr

I've simulated a container with a css that Canvas-slideUpIn applies. Apart from an animation, does this class have any other intended side effects? If not, is it not good practice to remove it after the animation is finished (and hence, its usefulness spent)?

If you do intend to to create a containing block for each webpart, you should probably have a another class for that intended purpose (e.g. class="Force-Containing -Block"). And if you do intend to have this side effect, the behavior should be consistent with single page apps but I don't see why you'd want that. Anyway, as you can see from #3218, I'm not the only one seeing this as a problem.

[StfBauer]

@semopz The documentation looks really nice. I wasn't aware of such a tool yet. Any chance you can provide a Repo with an actual SPFx solution? Otherwise, it would be hard to reproduce your issue other than building the solution myself. Which then still looks different than yours.

[semopz]

Thanks for your patience @StfBauer
I've created a working example that you can clone
https://github.com/semopz/examples/tree/master/toast

Even if you don't agree with the implementation of the tool, there's other implications of leaving the transform active on the webpart's parent element. The notifications library is just an example of the undesirable side effects of doing so.

[KevinTCoughlin]

We've confirmed this is a bug; thanks for the repros! We are evaluating removing the animation class on animationend to avoid the transform layer related problems with position: fixed;. Also to avoid SPFx developers from DOM manipulating as a workaround as that is an unsupported scenario.

[KevinTCoughlin]

We've merged a change that removes the animation per WebPart container on 'animationend'. This will remove the layer promotion done by the browser and allow for position: fixed; etc. cc: @andrewconnell @VesaJuvonen

[andrewconnell]

@semopz Can you monitor your tenant to verify when the fix has been rolled out? Once you see it, you can close. this issue. Thanks!

[semopz]

As of version 16.0.19805.12034, the fix is not yet available will update when I see change.

[semopz]

As of 16.0.19819.12035, Canvas-slideUpIn doesn't seem to linger anymore. Thank you all

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues