WICG / layout-instability

A proposal for a Layout Instability specification
https://wicg.github.io/layout-instability/
Other
158 stars 26 forks source link

Layout shift reported without actual visual shifting for resized fixed iframe #84

Open Andarist opened 3 years ago

Andarist commented 3 years ago

this is a re-post of this Lighthouse issue

Provide the steps to reproduce

Create a fixed iframe that is being resized with an element with it that has also a fixed positioning to stick it to the right edge.

screencast 2020-09-14 12-06-54

The border has been added on the outer element to visualize what is changing (the fixed container of the iframe on the page).

What is the current behavior?

CLS is being reported.

What is the expected behavior?

No CLS should be reported here - there is no visual effect for the user.

I understand that the use case here is very specific, but it shows that the current heuristics do not account for more complex scenarios. It's not sufficient to compute the layout shift of the element in relation to its viewport - the computation should account for nested frames.

Given that this is a user-centric metric and a user is not impacted in a meaningful way in scenarios like this then it would be great if this just wouldn't result in a false positive (from the user's perspective).

anniesullie commented 3 years ago

Can you post a reduced test case (html and javascript of a page that has this problem)?

Andarist commented 3 years ago

It took me a little bit longer to get back to this topic but here are several demos of the problem.

This demo is using an absolute iframe within a fixed container: https://codesandbox.io/s/serene-hertz-r4vzt This might look like a weird setup but it's used by several widget-based products due to layout quirks. Even today we suffer from cross-browser issues and this one aims to fix a problem on mobile Chrome as far as I remember. Unfortunately, I don't have any more info beyond that because it's layout that we are already using for some time and we had to iterate to get to it but we have not documented the process and exact problems that we have been suffering when using different layouts. The last change done to this was 100% related to mobiles browsers.

This demo is using a fixed iframe without any container: https://codesandbox.io/s/vibrant-breeze-5ohj6 Note: there is no visual difference between both of them. Yet this one doesn't have any layout shifts reported on the main page.

This is an additional demo that is somewhat offtopic to the main problem but it also related to the layout shifts. Maybe you would know if this repo is the appropriate place to report this (might not be as I don't see anything svg-related in the spec) or should we maybe report this directly to Chromium as an implementation bug. The problem here is that <svg></svg> (even an empty one!) within an iframe that gets resized is triggering layout shift reports within the iframe, even though the very same markup just with an empty <div></div> instead of the SVG doesn't suffer from the same: https://codesandbox.io/s/elegant-robinson-mvpk7

mmocny commented 3 years ago

I just tried that first repro link (https://codesandbox.io/s/serene-hertz-r4vzt) and I don't see a shift reported, nor can I find it through DevTools inspection. I may just be "holding it wrong" and maybe I'm not using the demo correctly.

I wanted to check: can anyone still repro this case?

Andarist commented 3 years ago

I've just retested this using the given codesandbox and I got those logs (that are a sign of the layout shift being reported):

Screenshot 2021-09-13 at 15 01 03

Strangely - I can't repro it when refreshing. When I've opened the associated "standalone" page ( https://r4vzt.csb.app/ ) I got a single log as well. The same thing happened though - couldn't repro it anymore when refreshing. I've found out that forking the codesandbox helps with reproducing it - you might be able to see a log for a "fresh" sandbox.