Discussion: add a way to show a modal

[NV]

Existing extensions, such as Omni, inject a content script on every single website only to display a popup in the middle of the screen.

This is bad for several reasons:

• Excessive permissions [updated: using activeTab mitigates that]
• Doesn't work at all on the new tab page (and the rest internal browser pages)
• The popup code can break the website, and the website code can break the popup (mitigated with but still may conflict with the website's elements).

As of today, Omni doesn't have any other way to display a modal (or chromeless window) in the middle of the screen.

I'm working on an extension that somewhat resembles Cmd-T UI from Arc:

Much like Omni, it displays a modal in the middle of the screen.

Modal API

How is it different from the dialog element?

1. It doesn't interfere with the . When both and extension's modal are present, the latter would be on top.
2. It fades out the entire browser UI, not just the web page. Much like the existing file picker UI, for example:

How would the API look?

browser.modal.open(chrome.runtime.getURL("modal.html"), options)

options:

center	true/false Default to true When present, top/left options are ignored
top/left	Distance of the dialog box from the top/left edge of the active browser window (or desktop, when there are no windows), in pixels
width/height	The width and hight of the dialog box in pixels.

Events:
browser.modal.onOpened
browser.modal.onClosed

Prior work:

• showModalDialog API, now deprecated.
• Dialog API

---

This is a continuation of #307, which we decided to close (as noted in the meeting notes).

[fregante]

You don't need extensive permissions to do that, but just activeTab and commands.

1. Register command that injects script
2. Immediately open the modal when the script is injected

I do this to inject sidebars, "cmd-k" palettes and other types of modal.

For the visual part of the equation, the upcoming popup element covers pretty much every issue you mentioned.

---

However I do agree that extensions are extremely limited UI-wise and they're always dependent on the host page (e.g. if the host navigates away, the extension is lost). It would be nice to have such a layer on top of tabs (not necessarily a modal) and as a standalone document.

[NV]

the upcoming popup element covers pretty much every issue you mentioned.

What upcoming popup element? I've found OpenUI's popup, but I imagine that's not what you meant.

[fregante]

That's pretty much it, but that page doesn't do it justice. Here it is, recently renamed to popover (attribute):

• https://developer.chrome.com/blog/pop-ups-theyre-making-a-resurgence/
• https://chromestatus.com/feature/5463833265045504

That article has a demo with exactly for what you're suggesting:

YZYZwDE0PQB9Qte16F7R.mp4

[NV]

I see. This is quite similar to the dialog element.

As you pointed out, hiding the popover when the page navigates is a genuine concern.

Also, injecting a script still has the limitations I mentioned above: it can't run on internal pages (the new tab page and other chrome:// pages, for instance).

[fregante]

it can't run on internal pages (the new tab page and other chrome:// pages, for instance).

If such a UI were to ever be implemented I'm going to assume those pages will be off-limits still because you know a malicious extension will eventually add an overlay onto chrome://extensions

[mon-jai]

The popup code can break the website, and the website code can break the popup (mitigated with but still may conflict with the website's elements).

Maybe Shadow DOM can be used?

[dotproto]

You don't need extensive permissions to do that, but just activeTab and commands.

An extension doesn't need broad host permissions, but this approach still gives the extension full access to the document once invoked. Ideally, extensions would have a way to put UI in front of the user without receiving access to sensitive data unnecessarily.

[fregante]

without receiving access to sensitive data unnecessarily.

What's the incentive? activeTab is "free" (as in, the user never knows it even exists). Unless and until that permission becomes visible to the user, as a privacy-conscious developer I can just continue to not read sensitive data.

The only reason would be that Chrome could then allow such overlays on chrome:// pages, but my guess is that even without access to the DOM you still won't allow that (with good reason)

I still agree that extensions would benefit from better UI access (popovers, sidebars) that doesn't require interacting with the current document, but "access" doesn't sound like an issue.

[oliverdunk]

Switching this to neutral. I am still very interested in such an API personally, but it isn't something Chrome is likely to prioritize and I don't think there are clear next steps right now.