1203394 - alert() in background scripts should warn that it doesn't work

Status: VERIFIED FIXED

(WebExtensions :: Untriaged, defect)

Description

[Will Bamberg [:wbamberg]]

Attachment: test.xpi

I've attached a WebExtension that loads 2 background scripts. The first just logs a string, the second displays an alert when the user clicks a button. It works as expected in Chrome. In Firefox (43.0a1 (2015-09-09)), I get this in the console:

NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMWindowUtils.isParentWindowMainWidgetVisible] nsPrompter.js:356:0

out of memory ExtensionUtils.jsm:24:0

Comment 1

[Will Bamberg [:wbamberg]]

Actually, it seems as if two scripts are not needed for this. You just need one background script, listening for a click on a browser action. I'll attach a new example.

Comment 2

[Will Bamberg [:wbamberg]]

Attachment: bug.xpi

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Finally had a chance to take a look at this. I could see this being important for developers writing "My first WebExtension". The "out of memory" message is incorrect and unfortunate (probably some xpconnect bug). But the real problem is that we don't support alert() in background pages.

Comment 4

[Andy McKay]

Based on the comments in bug 1214174, let's have just one bug.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Going to un-dupe this since we might want to implement alert().

Comment 6

[Blake Winton (:bwinton) (:☕️)]

As a side note, someone in the wild just ran into this, and asked about it at http://stackoverflow.com/questions/34199130/firefox-entension-alert

Comment 7

[Kris Maglione [:kmag]]

I've been thinking we should just alias this to console.log, and also print a warning that console.log should be used instead when it's called. And possibly open up the browser console if it's not open at the time.

That would be a good first bug, I think.

Comment 8

[Kris Maglione [:kmag]]

The relevant code is here:

https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/ext-backgroundPage.js#64

I think the way to handle this is to add a DOMWindowCreated[1] listener to the content window, and then use exportFunction[2] to replace the window's `alert` function with one that calls the window's `console.log`, and then opens up the browser console (using `HUDService.openBrowserConsoleOrFocus()`)


[1]: https://developer.mozilla.org/en-US/docs/Web/Events/DOMWindowCreated
[2]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Language_Bindings/Components.utils.exportFunction

Comment 9

[tofumatt [:tofumatt]]

Attachment: MozReview Request: bug 1203394: alias alert() to console.log() in background scripts r?kmag

Review commit: https://reviewboard.mozilla.org/r/39775/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/39775/

Comment 10

[Kris Maglione [:kmag]]

https://reviewboard.mozilla.org/r/39775/#review37279

::: toolkit/components/extensions/ext-backgroundPage.js:83
(Diff revision 1)
> +          if (!consoleWindow) {
> +            let { require } = Cu.import("resource://devtools/shared/Loader.jsm", {});
> +            require("devtools/client/framework/devtools-browser");
> +            let hudservice = require("devtools/client/webconsole/hudservice");
> +            let { console } = Cu.import("resource://gre/modules/Console.jsm", {});
> +            hudservice.toggleBrowserConsole().then(null, console.error);

I'd go with `hudservice.toggleBrowserConsole().catch(Cu.reportError)`

::: toolkit/components/extensions/ext-backgroundPage.js:95
(Diff revision 1)
> +
> +          alertDisplayedWarning = true;
> +        }
> +
> +        window.console.log(text);
> +      }

Semicolon.

::: toolkit/components/extensions/ext-backgroundPage.js:96
(Diff revision 1)
> +          alertDisplayedWarning = true;
> +        }
> +
> +        window.console.log(text);
> +      }
> +      Components.utils.exportFunction(alertOverwrite, this.contentWindow, {

Let's use `window` rather than `this.consoleWindow` just so we're consistent.

::: toolkit/components/extensions/test/mochitest/mochitest.ini:69
(Diff revision 1)
>  skip-if = buildapp == 'b2g' # unimplemented api.
>  [test_ext_alarms.html]
>  [test_ext_background_window_properties.html]
>  [test_ext_background_sub_windows.html]
>  [test_ext_background_api_injection.html]
> +[test_ext_background_page.html]

Looks like you forgot to add this test file?

Comment 11

[tofumatt [:tofumatt]]

Comment on attachment 8730247 [details]
MozReview Request: bug 1203394: alias alert() to console.log() in background scripts r?kmag

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/39775/diff/1-2/

Comment 12

[Kris Maglione [:kmag]]

Comment on attachment 8730247 [details]
MozReview Request: bug 1203394: alias alert() to console.log() in background scripts r?kmag

https://reviewboard.mozilla.org/r/39775/#review44221

Very close. The tests just need to deal with the browser console window that we're opening.

It would be great if we could get this landed before the 48 merge on Monday

::: toolkit/components/extensions/test/mochitest/test_ext_background_page.html:16
(Diff revision 2)
> +<body>
> +
> +<script type="text/javascript">
> +"use strict";
> +
> +

Please remove extra blank line.

::: toolkit/components/extensions/test/mochitest/test_ext_background_page.html:20
(Diff revision 2)
> +
> +
> +const Services = SpecialPowers.Services;
> +
> +ok(!Services.wm.getEnumerator("alert:alert").hasMoreElements(),
> +   "Alerts should not be present at the start of the test.");

This needs to happen within a task. Tests are technically not allowed to log results during setup or teardown, so even if this works now, it's likely to break in the future.

::: toolkit/components/extensions/test/mochitest/test_ext_background_page.html:40
(Diff revision 2)
> +  info("startup complete loaded");
> +
> +  yield extension.awaitFinish("alertCalled");
> +
> +  var alertWindows = Services.wm.getEnumerator("alert:alert");
> +  ok(!alertWindows.hasMoreElements(), "Should not show alert");

We should check that the browser console is open here, and that it has a message. And we definitely need to close the browser console at the end of the test. Leaving it open is likely to cause other tests to fail.

Let me know if you need any help with this.

::: toolkit/components/extensions/test/mochitest/test_ext_background_page.html:44
(Diff revision 2)
> +  var alertWindows = Services.wm.getEnumerator("alert:alert");
> +  ok(!alertWindows.hasMoreElements(), "Should not show alert");
> +
> +  yield extension.unload();
> +});
> +

Please remove blank line.

Comment 13

[tofumatt [:tofumatt]]

https://reviewboard.mozilla.org/r/39775/#review44221

> This needs to happen within a task. Tests are technically not allowed to log results during setup or teardown, so even if this works now, it's likely to break in the future.

If I move the code inside a task I get errors about `ok` and `Services` being undefined. How do I run them inside a task?

> We should check that the browser console is open here, and that it has a message. And we definitely need to close the browser console at the end of the test. Leaving it open is likely to cause other tests to fail.
> 
> Let me know if you need any help with this.

Yeah, could you point me to a test I could copy or refer to? I did this for my last patch but it wasn't a mochitest, so I don't know how to do it here :-/

Comment 14

[Kris Maglione [:kmag]]

https://reviewboard.mozilla.org/r/39775/#review44221

> If I move the code inside a task I get errors about `ok` and `Services` being undefined. How do I run them inside a task?

That shouldn't happen. Can you show me the code?

> Yeah, could you point me to a test I could copy or refer to? I did this for my last patch but it wasn't a mochitest, so I don't know how to do it here :-/

I think we're going to have to make this a chrome test for this to work properly, since we need to check this from the parent process. So just move the line that registers the test from mochitest.ini to chrome.ini.

The code to check for and close the browser console should look something like this:

    let haveConsole = !!HUDService.getBrowserConsole();
    ok(haveConsole, "Expected browser console to be open");
    if (haveConsole)
      yield HUDService.toggleBrowserConsole();
    }

And to check for the message, do something like `Cc["@mozilla.org/consoleAPI-storage;1"].getService(Ci.nsIConsoleAPIStorage).getEvents()`, and then check that the last event is what you'd expect.

Comment 15

[tofumatt [:tofumatt]]

https://reviewboard.mozilla.org/r/39775/#review44221

> That shouldn't happen. Can you show me the code?

Sorry, I'm dumb; you're right. I was putting it in the extension code. I put it inside the task but not the extension and it was all good.

Comment 16

[tofumatt [:tofumatt]]

https://reviewboard.mozilla.org/r/39775/#review44221

> I think we're going to have to make this a chrome test for this to work properly, since we need to check this from the parent process. So just move the line that registers the test from mochitest.ini to chrome.ini.
> 
> The code to check for and close the browser console should look something like this:
> 
>     let haveConsole = !!HUDService.getBrowserConsole();
>     ok(haveConsole, "Expected browser console to be open");
>     if (haveConsole)
>       yield HUDService.toggleBrowserConsole();
>     }
> 
> And to check for the message, do something like `Cc["@mozilla.org/consoleAPI-storage;1"].getService(Ci.nsIConsoleAPIStorage).getEvents()`, and then check that the last event is what you'd expect.

My only issue here is that `HUDService` is undefined and trying to import it doesn't work. How do I get access to that API?

Comment 17

[tofumatt [:tofumatt]]

https://reviewboard.mozilla.org/r/39775/#review44221

> My only issue here is that `HUDService` is undefined and trying to import it doesn't work. How do I get access to that API?

Same with "Cc"; I don't know what that's supposed to mean. Is there a good doc page for finding this stuff? My Googling has turned up a lot of API docs but they don't seem to work in the tests.

Comment 18

[Kris Maglione [:kmag]]

(In reply to tofumatt [:tofumatt] from comment #16)
> My only issue here is that `HUDService` is undefined and trying to import it
> doesn't work. How do I get access to that API?
>
> Same with "Cc"; I don't know what that's supposed to mean. Is there a good
> doc page for finding this stuff? My Googling has turned up a lot of API docs
> but they don't seem to work in the tests.

Hm. Well, usually Cc and Ci are defined for all of our tests in the head.js
file, but we don't currently have a separate head.js file for chrome
mochitests, so in this case they're not. You just need to add something like
this to the beginning of the script:

    var {classes: Ci, interfaces: Ci, utils: Cu, results: Cr} = Components;

As for HUDService, you need to import it the same way you do in
ext-backgroundPage.js:

    let {require} = Cu.import("resource://devtools/shared/Loader.jsm", {});
    require("devtools/client/framework/devtools-browser");
    let HUDService = require("devtools/client/webconsole/hudservice");

Comment 19

[Kris Maglione [:kmag]]

https://reviewboard.mozilla.org/r/39775/#review44537

::: toolkit/components/extensions/ext-backgroundPage.js:79
(Diff revision 2)
> +      let alertDisplayedWarning = false;
> +      let alertOverwrite = text => {
> +        if (!alertDisplayedWarning) {
> +          let consoleWindow = Services.wm.getMostRecentWindow("devtools:webconsole");
> +          if (!consoleWindow) {
> +            let { require } = Cu.import("resource://devtools/shared/Loader.jsm", {});

Sorry, I should have noticed this before. ESLint will reject this for the whitespace inside the braces. Same for the one below.

Comment 20

[tofumatt [:tofumatt]]

Comment on attachment 8730247 [details]
MozReview Request: bug 1203394: alias alert() to console.log() in background scripts r?kmag

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/39775/diff/2-3/

Comment 21

[Kris Maglione [:kmag]]

Comment on attachment 8730247 [details]
MozReview Request: bug 1203394: alias alert() to console.log() in background scripts r?kmag

https://reviewboard.mozilla.org/r/39775/#review45245

::: toolkit/components/extensions/test/mochitest/test_chrome_ext_background_page.html:50
(Diff revision 3)
> +
> +  // Make sure the message we output to the console is seen.
> +  // This message is in ext-backgroundPage.js
> +  let events = Cc["@mozilla.org/consoleAPI-storage;1"]
> +    .getService(Ci.nsIConsoleAPIStorage).getEvents();
> +  ok(events[events.length - 1], "alert() is not supported in background windows; please use console.log instead.")

This will only check that there was an event, not that it was correct. I think you need to check `event.arguments[0]` (using `eq` rather than `ok`)

::: toolkit/components/extensions/test/mochitest/test_chrome_ext_background_page.html:57
(Diff revision 3)
> +  let {require} = Cu.import("resource://devtools/shared/Loader.jsm", {});
> +  require("devtools/client/framework/devtools-browser");
> +  let hudservice = require("devtools/client/webconsole/hudservice");
> +
> +  let consoleWindow = Services.wm.getMostRecentWindow("devtools:webconsole");
> +  if (!consoleWindow) {

This makes the next test invalid. We're supposed to be testing that the console window was opened by the extension, but this will open it if it's not already open.

::: toolkit/components/extensions/test/mochitest/test_chrome_ext_background_page.html:58
(Diff revision 3)
> +  require("devtools/client/framework/devtools-browser");
> +  let hudservice = require("devtools/client/webconsole/hudservice");
> +
> +  let consoleWindow = Services.wm.getMostRecentWindow("devtools:webconsole");
> +  if (!consoleWindow) {
> +    yield hudservice.toggleBrowserConsole().catch(Cu.reportError);

The `.catch(...)` isn't necessary. The `yield` will cause it to throw, and the test to fail, if the promise is rejected. Which is what we want.

Comment 22

[tofumatt [:tofumatt]]

https://reviewboard.mozilla.org/r/39775/#review45245

> This makes the next test invalid. We're supposed to be testing that the console window was opened by the extension, but this will open it if it's not already open.

Hmm, any idea why the test would fail without it then? It totally works when I launch Nightly and run an extension using alert() in the background, but the test fails without this :-(

Comment 23

[tofumatt [:tofumatt]]

https://reviewboard.mozilla.org/r/39775/#review45245

> This will only check that there was an event, not that it was correct. I think you need to check `event.arguments[0]` (using `eq` rather than `ok`)

eq doesn't seem to be available, but I see "is" being used elsewhere and it looks like it's comparing things like an eq() helper. Is that okay?

Comment 24

[tofumatt [:tofumatt]]

https://reviewboard.mozilla.org/r/39775/#review45245

> eq doesn't seem to be available, but I see "is" being used elsewhere and it looks like it's comparing things like an eq() helper. Is that okay?

Also, `events.arguments[0]` is undefined, and `event` doesn't exist. I'm confused.

Comment 25

[Kris Maglione [:kmag]]

https://reviewboard.mozilla.org/r/39775/#review45245

> Hmm, any idea why the test would fail without it then? It totally works when I launch Nightly and run an extension using alert() in the background, but the test fails without this :-(

It may be timing-related. `toggleBrowserConsole` is asynchronous, so the window may not be open by the time you check. When you `yield` on the result of `toggleBrowserConsole`, it actually waits. I don't see an obvious way to handle this, but the code is here: https://dxr.mozilla.org/mozilla-central/source/devtools/client/webconsole/hudservice.js#172

Comment 26

[Kris Maglione [:kmag]]

https://reviewboard.mozilla.org/r/39775/#review45245

> Also, `events.arguments[0]` is undefined, and `event` doesn't exist. I'm confused.

Sorry, yeah, `is`. We have different names for test functions in each suite...

`event` as in `event = events[events.length - 1]`

Comment 27

[Kris Maglione [:kmag]]

https://reviewboard.mozilla.org/r/39775/#review45253

::: toolkit/components/extensions/ext-backgroundPage.js:83
(Diff revision 3)
> +          if (!consoleWindow) {
> +            let {require} = Cu.import("resource://devtools/shared/Loader.jsm", {});
> +            require("devtools/client/framework/devtools-browser");
> +            let hudservice = require("devtools/client/webconsole/hudservice");
> +            let {console} = Cu.import("resource://gre/modules/Console.jsm", {});
> +            hudservice.toggleBrowserConsole().catch(Cu.reportError);

Ugh. This should be `openBrowserConsoleOrFocus`. I can't believe I missed that.

Comment 28

[tofumatt [:tofumatt]]

Comment on attachment 8730247 [details]
MozReview Request: bug 1203394: alias alert() to console.log() in background scripts r?kmag

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/39775/diff/3-4/

Comment 29

[Kris Maglione [:kmag]]

Comment on attachment 8730247 [details]
MozReview Request: bug 1203394: alias alert() to console.log() in background scripts r?kmag

https://reviewboard.mozilla.org/r/39775/#review45285

::: toolkit/components/extensions/test/mochitest/test_chrome_ext_background_page.html:62
(Diff revision 4)
> +
> +  let {require} = Cu.import("resource://devtools/shared/Loader.jsm", {});
> +  require("devtools/client/framework/devtools-browser");
> +  let hudservice = require("devtools/client/webconsole/hudservice");
> +
> +  hudservice.getBrowserConsole();

Let's make this something like `while (!hudservice.getBrowserConsole()) { yield new Promise(resolve => setTimeout(resolve, 0)) }`

Comment 30

[tofumatt [:tofumatt]]

Comment on attachment 8730247 [details]
MozReview Request: bug 1203394: alias alert() to console.log() in background scripts r?kmag

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/39775/diff/4-5/

Comment 31

[tofumatt [:tofumatt]]

Comment on attachment 8730247 [details]
MozReview Request: bug 1203394: alias alert() to console.log() in background scripts r?kmag

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/39775/diff/5-6/

Comment 32

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f81f6da28c66

Comment 33

[tofumatt [:tofumatt]]

Attachment: alerteslintfixes.patch

Patch to fix eslint errors in previous, landed patch.

Comment 34

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b81b43e9f468

Comment 35

[tofumatt [:tofumatt]]

Attachment: alert-test-fixes.patch

Skip Android test for alert()

Comment 36

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b1412d274f62

Comment 37

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Comment on attachment 8744957 [details] [diff] [review]
alert-test-fixes.patch

Review of attachment 8744957 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/b1412d274f62

Comment 38

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Test got disabled in https://hg.mozilla.org/integration/mozilla-inbound/rev/29d97c105fc5

Comment 39

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f81f6da28c66
https://hg.mozilla.org/mozilla-central/rev/b81b43e9f468
https://hg.mozilla.org/mozilla-central/rev/b1412d274f62
https://hg.mozilla.org/mozilla-central/rev/29d97c105fc5

Comment 40

[zheaddaggue]

could someone please clarify ... is this the permanent "fix" or just a stopgap until alert() can be properly implemented? should I open a new bug for proper implementation of alert()?

i'm trying to move a "legacy" extension to webextensions that alerts info about an element via the context menu; it's very upsetting if this functionality will not be supported.

Comment 41

[Kris Maglione [:kmag]]

This is meant to make things easier for people who try to use alert() for debugging. We don't intend to support alert() in background pages.

If you want to alert data based on a context menu item, you can do so from a content script.

Comment 42

[zheaddaggue]

do I understand correctly that you're telling me that functionality cannot be accessible via native Firefox context menus?

can't this alias to nsIPromptService's alert? (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIPromptService#alert())

all i want to do is alert an input's maxlength, where applicable, so as to inform allowable length for password generation, etc.

Comment 43

[Kris Maglione [:kmag]]

I'm telling you that it won't be accessible from background pages. Alerts are modal dialogs, and they're meant to be tied to a specific, user-visible window. If you want to trigger an alert from a context menu operation, it needs to be triggered from the appropriate content window.

Comment 44

[zheaddaggue]

I'm presuming content scripts cannot create native Firefox context menus. is that correct? is there no way for a native Firefox context menu to produce a native firefox interface for displaying information to the user (other than via browser console, for obvious reasons)?

Comment 45

[zheaddaggue]

nsIPromptService's alert() is different from the web API window.alert(). it isn't tied to a particular tab. it's tied to the firefox browser window.

Comment 46

[zheaddaggue]

the web API version also can't be relied upon because it can be overridden by the web content to do other things, e.g.

function alert(message) { 
 console.info(message);
}

Comment 47

[Kris Maglione [:kmag]]

(In reply to zheaddaggue from comment #44)
> I'm presuming content scripts cannot create native Firefox context menus. is
> that correct? is there no way for a native Firefox context menu to produce a
> native firefox interface for displaying information to the user (other than
> via browser console, for obvious reasons)?

You can create a context menu item from a background script and then use a
content script to display the alert.

(In reply to zheaddaggue from comment #45)
> nsIPromptService's alert() is different from the web API window.alert(). it
> isn't tied to a particular tab. it's tied to the firefox browser window.

It's not. window.alert is implemented using nsIPromptService. The alerts are
modal to whatever window the caller chooses for them to be modal to.

(In reply to zheaddaggue from comment #46)
> the web API version also can't be relied upon because it can be overridden
> by the web content to do other things, e.g.

No, it can't be overridden by web content. Content scripts executed in a
different scope from page scripts, and are guaranteed access to a clean set of
web APIs.

Comment 48

[Vasilica Tamas, QA [:vtamas]]

I was able to reproduce the initial issue on Firefox 48.0.2 (20160823121617) under Windows 10 64-bit.

Manually verified as fixed on Firefox 49 (20160912134115), Firefox 50.0a2 (2016-09-15) and Firefox 51.0a1 (2016-09-15) under Windows 10 64-bit. “You clicked” log successfully appeared and the error is no longer thrown in Browser Console.

Comment 49

[Danny Lin]

This issue is still reproduced on Firefox 52.0a2 (2017-01-22) / Windows 7 SP1.

There is no alert shown, and the console shows "alert() is not supported in background windows; please use console.log instead."

Comment 50

[tofumatt [:tofumatt]]

(In reply to Danny Lin from comment #49)
> This issue is still reproduced on Firefox 52.0a2 (2017-01-22) / Windows 7
> SP1.
> 
> There is no alert shown, and the console shows "alert() is not supported in
> background windows; please use console.log instead."

Hi Danny, that's actually the correct behaviour; I guess the title of the bug is a bit misleading. Because it's a background script alert() will never work. That message is the correct outcome; it's letting you know that there aren't alert()s available in the script and to use console.log instead. :-)

Comment 51

[Danny Lin]

(In reply to tofumatt [:tofumatt] from comment #50)

Is there currently a way to show alert(), confirm(), or prompt() for chrome.browserAction.onClicked? If yes, how?

Comment 52

[Wojciech Walek [:wojwal]]

Just faced this issue...

I'm actually migrating from Chrome Extension to Firefox WebExtension - it all works properly in Chrome - displays the alert (the URL in alert dialog is just empty). 

Implemented "console.log" solution looks more like a temporary patch then a solution. Dear mozilla developers - simple things should remain simple... Using Background -> Content-Script communication just to show alert is reinventing the wheel in my opinion. Why don't you just show it on currently focused window - just like Chrome is doing? 

I'm on Firefox 52.0 - "alert" was patched - but "confirm" and "prompt" - are still throwing:

NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMWindowUtils.isParentWindowMainWidgetVisible]

------------------------

In addition - passing Background -> Content-Script (or picking currently focused Window - or whatever it takes to do it), can be done:
1. Once - by a mozilla developer
2. Thousands of time - by extensions developer in each extension

Comment 54

[erosman]

ref:

The purpose of this bug (bug 1353637) was to state why it is needed to have alert/confirm/prompt from background script, like other browsers such as Chrome. In other words, why it is necessary to change the status que.

The other referenced bug (this topic) does not answer this question. Instead it states that it is how Firefox is dong it at the moment.

The status of "bug has been fixed and VERIFIED for Firefox 49" does not reflect accurately.

Alert() bug was not fixed. It was decided to output a log instead of alert() which is not what alert() is for.
If the desired effect was to output to the console, developers would have used the console.log and not alert()

This 2 year old topic seems to deal mainly with errors resulting from using alert from background script rather than the merit of having alert/confirm/prompt from the background script (as was requested in bug 1353637).

Comment 55

[Kris Maglione [:kmag]]

This has already been discussed ad nauseum.

We aren't going to implement the ability to open modal dialogs from background pages. There are important technical reasons that they're problematic, and important UX ones as well.

This bug is fixed to the extent that it is ever going to be fixed.

If you want to continue this discussion, please do it elsewhere. The dev-platform and dev-firefox groups might be appropriate.

Comment 57

[Kuba Niewiarowski]

Should be either resolved wontfix or description changed to something less misleading. Calling issue with alert() not working from background script "fixed" is obvious overvaluation.

Comment 58

[Kuba Niewiarowski]

I don't think that is any more appropriate place for discussion about bug status meaning and it's clarity than bug itself.

Comment 59

[Tomislav Jovanovic :zombie]

Please don't go around needinfo-ing people on old bugs, it accomplishes nothing.