Should the ICB resize as UA UI gets shown/hidden?

[bramus]

Upon loading a page in a Mobile Browser, the ICB assumes the size of the (Layout) Viewport, as per spec.

The containing block in which the root element1 lives is a rectangle called the initial containing block. For continuous media, it has the dimensions of the viewport2

More specifically, it takes over the size of the “Small Viewport”

As found through testing, the ICB gets resized in the following browsers when the UA hides its dynamic toolbars:

• Firefox 102 on iOS
• Edge 103 on iOS

This behavior is theoretically correct, since the ICB size should follow the Layout Viewport size. Because the Layout Viewport gets resized when toolbars contract – to the size of the “Large Viewport” – the ICB could follow based on the current definition.

However, these browsers do not do that entirely: they resize the ICB to a size somewhere in between the size of the Small Viewport and Large Viewport.

A side-effect of resizing the ICB is that it affects the size of the Viewport Units. As specced, these units follow the size of the ICB:

The viewport-percentage lengths are relative to the size of the initial containing block

With a resized ICB, the size of the svh unit changes.

[bramus]

My take would be to not allow this resizing of the ICB in this case, as this feels very weird to have its value changed all of a sudden.

This can be specified by further tightening the definition of the ICB: specify that it has the dimensions of the Layout Viewport Small Viewport. This results in a stable svh unit that does not change size as UA UI Elements contract/expand.

[emilio]

FWIW I had filed the viewport units here: mozilla-mobile/firefox-ios#11574 and there was mozilla-mobile/firefox-ios#9385 already.

[bramus]

We just discussed this during meeting #4 and agree that the ICB should not resize as UA UI toolbars grow/retract. This excludes the Virtual Keyboard, which is discussed in #11

[bramus]

@dlibby- Are there bugs filed on Microsoft’s end to track this? If not, where can we file them?

[dlibby-]

I filed a bug for the iOS behavior but haven't gotten a response from the team yet (sorry no public bug database at this point in time).

AFAICT, the Android Edge behavior w.r.t. ICB is identical to Android Chrome. So if there are any issues (i.e. the outerHeight/innerHeight values or the fact that updates happen after the finger lifts), we can track in crbug. Does that sound good to you?

[bramus]

I filed a bug for the iOS behavior but haven't gotten a response from the team yet (sorry no public bug database at this point in time).

Awesome, thanks!

AFAICT, the Android Edge behavior w.r.t. ICB is identical to Android Chrome. So if there are any issues (i.e. the outerHeight/innerHeight values or the fact that updates happen after the finger lifts), we can track in crbug. Does that sound good to you?

If we can determine / get confirmation which browsers are being buggy for certain aspects, we need to follow-up (i.e. file bugs) with the engines themselves indeed.

For window.outerHeight specifically there’s #17. For window.innerHeight there’s #9

[bramus]

Closing this one, as follow-up bug reports have been filed by Emilio and (internally) Daniel. Thanks.