Open Bug 1513656 Opened 2 years ago Updated 23 days ago

alert/confirm/prompt dialogs do not work properly in the sidebar


(WebExtensions :: Frontend, defect, P3)

64 Branch


(Not tracked)



(Reporter: tim.weissenfels, Unassigned)



(4 files, 2 obsolete files)

Attached file (obsolete) —
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

Call alert(), confirm() or prompt() from a script running in the sidebar.

Actual results:

The dialog box fills the whole sidebar (*) but has a transparent background.
There is just the text and the buttons floating around on top of the page content.

* This might be intended but differs from dialog boxes in normal websites.

Expected results:

alert/confirm/prompt dialog boxes should have an opaque background (used to be white).
Attached image Screenshot of the bug (obsolete) —
confirm("confirm text") called from a sidebar script. The sidebar page has an orange background.
I created a simple web extension that demonstrates the bug and added a screenshot (see attachments)
Summary: alert/confirm/prompt do not work properly in the sidebar → alert/confirm/prompt dialogs do not work properly in the sidebar
Priority: -- → P2
Temporary fix for extension developers:

I can confirm this is a regression; prompt() in sidebars did work correctly in Firefox 63.0 (and is still broken in Firefox 65.0)

One more observation:
The bug behavior happens when installing the extension in a new profile of Firefox 65.0.
It does not occur when installing the extensions in a Firefox instance started by web-ext (in this case, the dialog is shown as a browser modal dialog).

Does this bug affect the options page?

Attachment #9030848 - Attachment is obsolete: true

@eight04 Can confirm, the bug also affects the options page (see updated attachments)

Attachment #9030847 - Attachment is obsolete: true

I have this problem too since a few versions. I’m on Firefox Developer Edition (67.0b11).

Note that this is still happening on 67.0, 68.0b2, 69.0a1.20190521.

This results in a poor experience for addon users when the addon needs to ask permission to the user.

I noticed it results in an extremely bad user experience if the dialog is opened a few times in a row.

Priority: P2 → P3

Now I am getting OperationError when calling prompt.

Firefox Developer Edition 72.0b10 (32-bit)

Is there a good way to implement dialogs on the options page? I can't find a way to display the dialog inside the viewport.

Should we switch to a popup?

The bug is still present, and I still don’t know how I’m supposed to warn the user before closing many tabs if I can’t use that.

Sure, I can create the dialog and open it as a popup of a browserAction, but that doesn’t sound like good design.

In my opinion, either the priority of the bug should be reconsidered, or the developers should be given a clear way to ask for ask users consent for some action.

You could also create a new popup window using the windows.create() API and create your dialogs & prompts that way.
But certainly it would be nice if the browser would provide this and you do not have to implement such basic UI things yourself.

Attached image Behavior in Firefox 63

Here are the results from some test I did:
– Working correctly in Firefox 62.0
– Half-working in Firefox 63.0 (dialog is opened in sidebar but doesn’t fit if sidebar is too thin; see attached file)
– Not working in Firefox 64.0 (and still not working as of today)

Summary of the previous information
– Still happening on 74.0 and 75.0b11.
– Not working when extension is installed normally or as temporary add-on loaded from about:debugging, but working when the extension is loaded on a temporary profile with web-ext.

I bisected and found the first commit to change the behavior from what we see in Firefox 62 and what we see in Firefox 63:

So apparently, how out-of-process extensions are handle are causing this. But why does it not happen when loaded when the extension is loaded through web-ext? I checked and there is a WebExtensions process that, when killed, breaks the add-on.

Regarding the previous comment, putting extensions.webextensions.remote to false doesn’t fix the bug and Firefox still create a WebExtensions process.

I’m still not sure if it was intended for dialog to open in the sidebar, but I’d like to insist that this is clearly incorrect, because it just won’t fit a dialog — the smallest width for the sidebar barely has space for an “OK” and a “Cancel” button, it doesn’t work with other OS/OS configuration and it just doesn’t work with a lot of languages.

I also tested to launch Firefox with web-ext, remove the installed add-on and install from within Firefox, and it still opens a new window. I suppose it happens because of the temporary profile (maybe the preferences changed?).

I bisected and found the first commit to change the behavior from what we see in Firefox 63 and what we see in Firefox 64:
A comment on top of the diff:

<!-- While these stylesheets are defined in Toolkit, they are only used in the
     main browser window, so we can load them here. Bug 1474241 is on file to
     consider moving these widgets to the "browser" folder. -->

I suppose this CSS should be added in browser/base/content/webext-panels.js but since it’s XUL, I don’t know how to do it.

I’ve compiled Firefox 30+ times for these bisect, and it was a pain because I had to apply fixes (too recent glibc, too recent Linux, and installing an old version of cbindgen).

So I’d really appreciate help to resolve the issue. Having the CSS applied back to the dialog should be really quick and could a first step, but I just don’t understand how Firefox decides to open a dialog in a new windows are inside the page.

Attachment #9066930 - Attachment description: Dialog in sidebar with «Disable “Prevent this page from creating additional dialogs» checkbox → Dialog in sidebar with “Prevent this page from creating additional dialogs” checkbox

Note that, and for the record, to compile those old versions of Firefox on Linux, I had to:

  • cargo install cbindgen --version 0.6.6 and put/link the executable in /usr/bin/cbindgen
  • Apply those two patches by hand (I used hg shelve and hg unshelve while moving between commits): commit 1, commit 2

Any news on this? Not being able to use a feature that’s been there forever on the web, and doesn’t have any easy-to-use alternative makes it very annoying to handle non-cancellable actions (e.g. closing tabs).

You need to log in before you can comment on or make changes to this bug.