Addressing auto-sizing of extension UI (options, popup, sidepanel)

[carlosjeurissen]

TLDR: This issue is a starting point to start talking about how to handle the sizing of extension views and discuss how to best address related issues.

Motivation and backstory

Historically, the viewport of html documents has always been determined by the browsers frame, being the browser window, browser tab, or browser popup size. The author of the html document can then base it's own styling and dimensions based on this size with units like vw and vh which in these situations are deterministic and non-ambiguous.

With the introduction of extensions, a new type of situation is born in which the author of the html document can, with certain restraints and many issues (which you can read about below) determine and change the size of the viewport by changing the height/width of the html/body elements. Examples are the extension popup and the options page if defined with options_ui.open_in_tab=false.

Status quo

Embedded options (options_ui)

Chrome

The width of the html/body element is used as width for the options dialog without a maximum.
The height of the html/body element is used as height with a maximum of the tab height minus ~128px to prevent the dialog from growing beyond the tab height.

Microsoft Edge desktop

The embedded options page has a fixed size of 400w x 450h independent of the size of the html/body element.

Mozilla Firefox

The embedded options page has a fixed width of 632px and a height which auto-adapts to the content. Meaning setting a value like 200vh will cause a loop.

Mobile

In most mobile browsers the options page opens in a new tab. Thus the viewport will be equal to the tab sizing.

Extension popups

In most browsers, extension popups auto adapt based on the html/body element with a maximum of 800w x 600h. This maximum can be smaller if the user uses a very small resolution. If the html/body element is set to be 600h this can cause double scrollbars.

On mobile, the extension popup is often opened as a normal browser tab. However on iOS mobile the popup opens as a bottom panel which seems to have the same dimensions as a normal tab and not respect the size of the html/body element.

The issues

In general as an extension you are not sure if your html documents are rendered in auto-size mode (with the html content determining the size) or if rendered with the browser having a fixed sizing independent of the html content. This is important because settings sizes to 100%/vh/vw will fail in auto-sized mode. While setting a fixed size will not render as expected in full-size tabs/panels.

The current situation causes a bunch of different issues like the auto-sizing is resulting into a loop (firefox options). Double scrollbars, unintended whitespace on the bottom and right. Off-screen content without being reachable with scrollbars and more. The extension authors currently have to either compromise on the result or apply all kind of hacks to get the result they want.

Ideal contract between browsers and extension authors

In an ideal world the extension would communicate (in any form, declarative in css for example) its preferred min/ideal/max height/width if in auto size. In which the ideal height/width could also mean "match" the browsers ideal sizing if it sits in between the min/max range. This preference is then incorporated by the browser and either fully or partially respected to render the auto-sized content.

This would open up all kind of other features like allowing a suggested sidepanel width and a bottom popup panel height.

Potential solutions

Media queries to determine auto-size mode.

Think about:

@media (auto-size: any) {
  html {
    heigth: 600px;
    width: 600px;
  }
}

The auto-size could be matched on none|any|width|height. Allowing browsers to only allow auto-sizing in one dimension if preferred (for the firefox options page for example).

This would address the issue with 100%/vh/vw. As you could use:

@media (auto-size: none) {
  html, body {
    heigth: 100%;
    width: 100%;
  }
}

Environmental variables

As an extension is can be useful to have the max and min sizes to prevent the issue of double scrollbars. Think about:

html, body {
    max-height: env(auto-size-max-height, 600px);
    max-width: env(auto-size-max-width, 800px);
}

Using @Viewport

While the @Viewport has been deprecated and might been removed completely. It could be useful in this situation to communicate the preferred values as described in the ideal contract.

@viewport {
  min-height: 400px;
  height: 600px;
  max-height: 800px;
}

Alternatively these could be set as directives on the <meta name="viewport">.

Prior art / related

There is some prior art in the CSSWG which discusses the auto-sizing of iframe elements on their parent document. See:
w3c/csswg-drafts#1771 and https://github.com/domenic/cooperatively-sized-iframes

Some of the techniques currently in use for the auto sizing and some of the proposals to accompany them can be reused/shared for auto-sizing of iframes.

With iframes, security is a concern so the auto-sizing can not be opt-in by default for both host and iframe. A potential way to address this would be adding a "autosize" keyword to the <meta name="viewport"> and an autosize attribute on the iframe.

Conclusion

These are some initial ideas in an attempt to improve the situation. Very open to ideas. @fregante @tabatkins @domenic @emilio @astearns @fantasai

[fregante]

Don’t your examples already work? Once you set fixed height/width on html that’s all the browser will use (within limits), effectively disabling autosizing. Any loops caused by viewport units should probably be reported as bugs and addressed by each browser. These loops also occasionally appear on the native web when scrollbars appear, changing the width of the content.

It might be useful to have a full repro to check out the issue and find a solution to it.

[carlosjeurissen]

@fregante thanks for looking at this!

Don’t your examples already work?

Do you mean currently in browsers or with some of the mentioned proposals?

Once you set fixed height/width on html that’s all the browser will use (within limits), effectively disabling autosizing.

Correct. This however will result in unintended whitespace at the bottom right when the html file is used as full size tab / bottom panel (iOS).

Any loops caused by viewport units should probably be reported as bugs and addressed by each browser. These loops also occasionally appear on the native web when scrollbars appear, changing the width of the content.

Yes. Often the loops can be addressed. Mentioned it as it is a side-effect of using the html/body tag as base size. Setting a percentage other than 100%/vw/vh will result in potential loops.

[emilio]

I think the biggest issue should be defining what auto-sizing really means. In Firefox, we basically have a mutation observer and some key events which trigger this kind of behavior (https://searchfox.org/mozilla-central/rev/43450868e9f3e26da88a02837e5a43c93728ea95/toolkit/components/extensions/ext-browser-content.js#176-196).

But as you noted, the behavior of viewport units and maybe percentage sizes isn't super well defined / something we'd really like... Detecting non-trivial cycles is also rather hard.