Thoughts on fixed viewport sizing

[theres-waldo]

Quoting from the "Fixed viewport size" section of the Web Viewports Explainer:

[In Chrome, t]he fixed viewport is sized to the minimum scale size. ... Since Chrome's the only one that's not sizing the fixed viewport to the ICB, perhaps we should change to that.

I'm trying to understand how that would work more precisely.

It seems to me like there are two sizes we can choosen from:

1. The size specified by the meta viewport tag.
2. Something derived from the content size, like the "minimum scale size".

IIUC, Chrome currently sizes the ICB to (1), and the fixed viewport to (2).

If we want the fixed viewport and the ICB are to have the same size, then it seems the options are:

• Size both to (1)

  This doesn't seem to be web compatible. On many sites, (1) is narrower (because they have a meta viewport tag with width=device-width), (2) is wider (because the content size is wider, and they don't have a minimum scale, or have a sufficiently small minimum scale), and they use overflow-x: hidden on the root element (see e.g. most of the sites in the webcompat issues linked to bug 1123938). Such sites currently:

  • Work fine in Chrome, because Chrome sizes the fixed viewport to (2).
  • Work fine in Safari, because even though Safari sizes the fixed viewport to (1), they seem to ignore overflow: hidden on the root element. (According to this comment they "used to" ignore overflow: hidden, but as far as I can tell they still do. I'm basing this on the fact that on this test page, which has a content size larger than the minimum scale size, Safari allows scrolling in the entire content area.)
  • Are broken in Firefox (in that the content that overflows (1) is "out of reach"), because Firefox sizes the fixed viewport to (1), and doesn't ignore overflow: hidden on the root element.

  . So, if Chrome plans to go with this option, it would either break such sites, or have to start ignoring overflow: hidden like Safari does to avoid breaking such sites.

• Size both to (2)

  This doesn't seem to work, because (2) is a function of the content size, which can depend on the ICB size (e.g. consider a document element with width: 50%), so trying to size the ICB to (2) would introduce a layout cycle.

David, could you clarify which of these options you had in mind, or perhaps something else I'm not thinking of?

[bokand]

I originally wanted to go with (1). Having taken a closer look through the webcompat issues in the bugzilla bug though, you're right - it might be a bit challenging with web compat. I wonder if we could run some telemetry and try to estimate based on real data what % of the web this would impact. In particular, pages that load zoomed in are less of a problem than those that load zoomed in but also have overflow-x: hidden since they're rendered unusable.

We definitely don't want to do (2) since the ICB must get its size from the viewport meta tag, I don't think we can change that. (As well as the cyclical dependency you mention).

If we could convince Safari to start respecting overflow: hidden on the root at the same time we could do that in concert. My experience when Chrome started respecting overflow: hidden was that we broke some small fraction of pages but authors quickly changed to fix them since its such a visible issue and easy fix. If it's uncommon enough maybe we could make the breaking change? I also need to better understand what's happening in Safari, the behavior on several of the examples in the bug was surprising to me based on my understanding of how it works.

[theres-waldo]

I wonder if we could run some telemetry and try to estimate based on real data what % of the web this would impact. [...] If it's uncommon enough maybe we could make the breaking change?

Good idea. I filed bug 1423017 to add telemetry to Firefox. Will you add some to Chrome as well?

[bokand]

Yup, filed https://crbug.com/792031 (though I'm off for a week starting tomorrow). Should be able to get it in for Chrome M65.

[theres-waldo]

I wonder if we could run some telemetry and try to estimate based on real data what % of the web this would impact. [...] If it's uncommon enough maybe we could make the breaking change?

Good idea. I filed bug 1423017 to add telemetry to Firefox. Will you add some to Chrome as well?

We added this telemetry to Firefox 62, and now have two release cycles worth of data from it.

Our telemetry classified pages into the following categories:

1. Page is not overflow-x: hidden OR page is overflow-x: hidden but the page content does not overflow the ICB horizontally.
2. Page is overflow-x: hidden and the page content overflows the ICB horizontally, but not the minimum scale size.
3. Page is overflow-x: hidden and the page content overflows the minimum scale size horizontally.

The idea behind this categorization is that:

• Pages in category 1 do not have content that's "out of reach" on any browser
• Pages in category 2 have content that's "out of reach" in Firefox, but not in Chrome or Safari
• Pages in category 3 have content that's "out of reach" in Firefox and Chrome, but not in Safari

The numbers show that 5-7% of pages are in category 2, and around 2% of pages are in category 3; the rest are in category 1.

You can see the data e.g. here for Firefox for Android beta 63, and adjust the parameters to see it for other channels. (Note that we don't collect telemetry on the release channel, only on nightly and beta.)

Solution (1) from upthread would break pages in category 2. [Note: They are currently broken in Firefox already, and we'd like to unbreak them. Solution (1) would break them in Chrome as well.] My assessment, based on these numbers, is that this approach is not web compatible.

David, what do you think? Were you able to add similar telemetry to Chrome?

[bokand]

Sorry, this fell off my plate and I never did add the telemetry. Thanks for doing that and the above summary. I'll add that now so that we can at least track it going forward and get some secondary confirmation - unfortunately it'll be ~6 weeks until we can get numbers out of beta.

I agree that ~6% of pages is awfully high for a breaking change. That's much higher than I would have expected from my own usage. Do the Firefox statistics count unique pages or as a proportion of total page loads?

[theres-waldo]

I agree that ~6% of pages is awfully high for a breaking change. That's much higher than I would have expected from my own usage.

Keep in mind, these are pages that work fine in Chrome, so assuming you're using Chrome, I wouldn't really expect them to stand out in any noticeable way.

Do the Firefox statistics count unique pages or as a proportion of total page loads?

I believe they count total page loads.

[theres-waldo]

Just wanted to close the loop here and say that, having determined approach 1 from upthread (size the ICB and the fixed viewport both to the size derived from the meta viewport tag) is not web compatible based on our telemetry, we implemented Chromium's current model (size the ICB to the size derived from the meta viewport tag, size the fixed viewport to the minimum scale size) in Firefox, as described in more detail in #9.

I'm going to close this issue now, but I'd like to note that our implementation is flexible in terms of choosing the size for the fixed viewport, and so if we decide to go with approach 1 at some future time, it should be a straightforward change for us.