Discuss allowing extensions to reliably draw over pages

[oliverdunk]

Many extensions have a need to draw UI over the page. Developers have traditionally relied on the stacking context and specific properties like z-index. These have always been limited but for the most part, do the job.

With the introduction of modals (via the <dialog> element), web developers can now draw to a new "top layer" that renders above everything else. Example: https://codepen.io/oliverdunk/pen/xxWKjOZ. This makes it much harder for extension developers as they now have to ensure UI is inside of the highest modal, and this could involve repeatedly moving their UI between DOM elements.

The ideal solution here would be a standardized mechanism - maybe a new layer - that extensions could put UI on. This would be reliable even as new standards are developed and provide the most robust long-term solution.

[oliverdunk]

From @dotproto:

I just poked through the HTML spec a bit to read up on the Dialog element. showModal() touches on a couple of important concepts for the sake of this discussion:

• Step 5 sets the is modal flag of the dialog to true
• Step 6 blocks the dialog's node document
• Step 7 adds the dialog to the node document's top layer

[jonathanKingston]

I just poked through the HTML spec a bit to read up on the Dialog element. showModal() touches on a couple of important concepts for the sake of this discussion

Dialog showModal has a lot of the properties that extensions want; however the page can call showModal after the extension and essentially click-jack the interface the extension wishes to present to the user.

• Ideally the extension could prevent further modals whilst theirs is open.

[birtles]

This makes it much harder for extension developers as they now have to ensure UI is inside of the highest modal, and this could involve repeatedly moving their UI between DOM elements.

Note that this is already the case for the full screen API -- that is, an extension needs to listen for fullscreen events and move their UI to be a descendant of document.fullscreenElement and back.

[Rob--W]

The concept of overlaying content on top of the current page (not necessarily embedded in the page) has come up many times before. Here's a feature request in Firefox for the generic functionality without any prescribed mechanism: https://bugzilla.mozilla.org/show_bug.cgi?id=1340930

Question to the extension devs here: Would action.openPopup cover the use cases (described in more detail at #160)? The extension popup panel can then host the content. From the user's perspective, the panel is clearly attributed to a specific extension.

[oliverdunk]

I think there are distinct use cases which aren't solved by openPopup, and would benefit greatly from the sort of thing proposed in that issue. In the case of 1Password, we want to show UI directly below input fields as this is an established UI pattern for offering field suggestions. We also have cases where we want to show notifications offering the user a suggested action without stealing focus away from the page.

It feels like drawing to the screen is a big part of allowing extensions to innovate. I could imagine, for example, an accessibility extension which highlights regions of the page to help someone navigate.

Something at a higher level than the main DOM would be really exciting because as @jonathanKingston mentioned, there's real scope for clickjacking issues when extensions are forced to put themselves in the DOM and compete with other scripts on the page to make sure they appear highest in the stacking order.

[birtles]

In the case of 1Password, we want to show UI directly below input fields as this is an established UI pattern for offering field suggestions. We also have cases where we want to show notifications offering the user a suggested action without stealing focus away from the page.

Pop-up dictionaries have similar requirements. That is, they need to pop-up next to or below the word being selected/hovered and typically without affecting the page's focus.

[hanguokai]

There is a new experiment(origin trial) Web API: Pop-up. Maybe this API can solve the problem in web pages.

Outside of web pages, like action.openPopup, new chrome.sidePanel api may also solve the problem for some cases.

[oliverdunk]

I opened an issue about this in the open-ui group (openui/open-ui#626) since I was curious to see if they wanted to tackle it together. They agreed it was an interesting problem but don't have the bandwidth to tackle it, so I think this is a good one to continue working on ourselves.

IIRC the action item from the last time this was discussed at a meeting was putting together an API proposal.

[fregante]

As discussed in today's meeting, browsers are already able to draw over pages via the dev tools. It would be great to expose this capability without having to alter the host page.

Example: Safari's dev tools drawn on this very page.

If this UI is painted via a standard "transparent" document, it might be good to expose it either via browser.dom.getOverlayDocument() or, as Firefox does in a somewhat related scenario, via window.overlayDocument. From there, the standard DOM API applies (with CSP to exclude scripting)