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?

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

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.

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.

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:
https://hg.mozilla.org/mozilla-central/rev/cb97b513e80eacbf60518002acd95f1591023bc7

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:
https://hg.mozilla.org/mozilla-central/rev/df5adaaa7e64ce2ba46c6bbaa1e02f555b08a603
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.

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).

It seems that the entire dialog feature is broken in the options page. I get this error on Firefox Dev 83.0b8 and the dialog doesn't display at all.

Prompter: Browser not available or tab modal prompts disabled. Falling back to window prompt. Prompter.jsm:1052
    set modalType resource://gre/modules/Prompter.jsm:1052
    setPropertyAsUint32 resource://gre/modules/Prompter.jsm:1706
    k/l["add-scope"]< moz-extension://52d773db-eea8-4ec8-a6c4-e91a9b456a4a/js/options.js:1
    (Async: EventListener.handleEvent)
    k moz-extension://52d773db-eea8-4ec8-a6c4-e91a9b456a4a/js/options.js:1
    <anonymous> moz-extension://52d773db-eea8-4ec8-a6c4-e91a9b456a4a/js/options.js:1
    <anonymous> moz-extension://52d773db-eea8-4ec8-a6c4-e91a9b456a4a/js/options.js:1
    (Async: promise callback)
    <anonymous> moz-extension://52d773db-eea8-4ec8-a6c4-e91a9b456a4a/js/options.js:1
    <anonymous> moz-extension://52d773db-eea8-4ec8-a6c4-e91a9b456a4a/js/options.js:1

For me it’s working again on the Option page on Firefox Developer Edition 84.0b1, with a nice modern look. It’s still broken in sidebars, though. Moreover, the dialog shouldn’t be in the sidebar because the sidebar can very tight.

OK I tested a bit more the current behavior (with Dev Edition 84.0b1), and it seems that:

• Normal use: It doesn’t work in sidebar (broken, transparent dialog window that’s half hidden because it’s too big for the sidebar width) but it works in an option page with new look (see screenshot)
• Dev use (that is to say, launched with a temporary profile via the web-ext tool): works in the sidebar with old look and doesn’t work in option page with the error described above.

Any updates on this? I am on stable Firefox 84.0 and facing the same issue.

Here is a popup alternative:
https://github.com/eight04/webext-dialog

Yeah sure I could use webext-dialog in Tab Center Reborn but frankly it just looks bad. I spend countless hours trying to make my extension look as close as possible as native Firefox, and it would look out-of-place. I tried to write my own implementation with the size of the dialog adapted to my text and the appearance as good as possible, but it’s a lot of work and then I would need need to adapt it to upcoming Firefox redesign.

I’m very frustrated because I spend hours trying to find where the problem was, and the issue is too complicated for me to fix it, at least without any help. I just would like this very simple and very useful feature back, instead of in a state of perpetual brokenness, to be able to use a one-line confirm dialog that works and looks good.

My hope at the moment is that somehow someone notices it and fixes it during the Proton Redesign.