javascript popups prevent closing tab

[Meekohi]

Binary package hint: firefox

If you land on an annoying site that constantly spams a javascript alert box on loop, it is impossible to close the associated tab, forcing the user to kill firefox and restart.

You should be able to close a tab even if a javascript alert box is open.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: firefox 3.6.6+nobinonly-0ubuntu0.10.04.1
ProcVersionSignature: Ubuntu 2.6.32-23.37-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-23-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Thu Jul 1 17:38:55 2010
FirefoxPackages:
 firefox 3.6.6+nobinonly-0ubuntu0.10.04.1
 firefox-gnome-support 3.6.6+nobinonly-0ubuntu0.10.04.1
 firefox-branding 3.6.6+nobinonly-0ubuntu0.10.04.1
 abroswer N/A
 abrowser-branding N/A
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox

[Cesar Eduardo Barros (cesarb)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17 i686; en-US; m18) Gecko/20001106
BuildID: 2000110608

The page in the URL (don't open it unless you know what you're doing!) "locks"
the user in an endless stream of JavaScript alerts. There is no way out; closing
the popup just opens a new one; UI is unresponsive in *any* place except the
popup; you can't cancel the loading of the page (or do something like ESC to
stop the script) since the UI is blocked by the popup. The perfect anti-Mozilla DoS.

Reproducible: Always
Steps to Reproduce:
1. Make sure there's nothing important open in Mozilla
2. Open the page
3. Try to escape the popup. You can't, you are stuck. Get ready to Ctrl+C Mozilla.

Actual Results: An annoying popup which won't go away.
All UI activity blocked by the popup.

Expected Results: Allowed one to cancel the script, or at least close/stop/back
the offending page.
Not blocked UI in other windows.

I found that URL while searching for 'bugscape' in google. I don't know the
significance of that.

[Junruh (junruh)]

Confirmed.

[Security-bugs (security-bugs)]

DoS attacks are low on my priority list right now. Marking Future.

[Security-bugs (security-bugs)]

*** This bug has been marked as a duplicate of 29346 ***

[Jruderman (jruderman)]

Actually a dup of some part of bug 22049 (which currently needs to be split
into several bugs).

[Junruh (junruh)]

Verified dupe.

[Jruderman (jruderman)]

Bug 22049 ended up covering too many different issues, so I'm reopening this
bug. I'm turning this one into "Alerts should be content-modal, not window-
modal"; see bug 61098 for another proposal that also might solve this problem.

[Matthew Paul Thomas (mpt)]

I suggest placing a Stop button (no text, just a stop icon, so as to be
unobtrusive) in the bottom left corner of any alert().

[Jruderman (jruderman)]

What would clicking the stop button do? Would it stop all network activity in
the window and all scripts on currently loaded pages? (That's more than I
think the stop button on the navigation toolbar should do.) Just prevent more
modal windows from coming up?

[Matthew Paul Thomas (mpt)]

The button would produce an additional alert asking if you wanted to stop all
scripts in the current page.

[Junruh (junruh)]

Qa > CKRITZER

[Bzbarsky (bzbarsky)]

*** Bug 117561 has been marked as a duplicate of this bug. ***

[Jruderman (jruderman)]

*** Bug 123007 has been marked as a duplicate of this bug. ***

[Bzbarsky (bzbarsky)]

*** Bug 123913 has been marked as a duplicate of this bug. ***

[M-mozilla (m-mozilla)]

Boris, I don't think bug 123913 is a straight dup of bug 59314.

Specifically, bug 123913 is an RFE for a crossplatform implementation of
"sheets" (a la Mac OS X) to implement the content-modality. Also, bug 123913
presuposes a fix in tabbed browsing which may well be addressed (or not
addressed) regardless of what happens in bug 59314.

For example, bug 59314 might be fixed by providing a magic keycommand which
aborts all scripts. I think... at least the bug 59314 comments indicate such...
actually, bug 59314 seems to have a bit of a split personality, and might be
best off *closed* in favor of two clear bugs: bug 123913 (which depends on bug
123908) and bug 61098)

From the other direction, bug 123913 could be fixed, and bug 59314 would still
hold: once you clicked into the offending tab, the tab would give you a sheet
with the alert and you might still have an application totally locked if the
stream of alerts never ended.

So, since each bug can be fixed independantly, I don't think they're dups, and
I'm de-duping...

-matt

[John Levon (levon)]

m_mozilla, I am in a quandary: look at bug 125829. It is clearly a dupe.

but of this bug or of bug 123908 ?

I would propose:

1) kill this bug. The DoS attack is covered by bug 61098

2) leave bug 123908 as-is (mac specific, tabs don't have sheets)

3) turn bug 125829 into an xp RFE for sheet-behaviour

4) make bug 123908 depend on bug 125829

Please people comment on this - good idea ?

[John Levon (levon)]

Aaagh, ignore me I missed bug 123913, and I duped it to that.

[R-contact2009-awhlink-com (r-contact2009-awhlink-com)]

Proposing to fix this bug for Mozilla 1.01.

[Security-bugs (security-bugs)]

ANdrew, are you offering to fix this? If so, assign it to yourself.

[Arthur (moz-liebesgedichte)]

*** Bug 136324 has been marked as a duplicate of this bug. ***

[John Levon (levon)]

*** Bug 138585 has been marked as a duplicate of this bug. ***

[Petertw-yahoo (petertw-yahoo)]

How simple would it be to add a user preference option under Advanced::Scripts
and Windows to disable Javascript popup alert()'s in the mean time? In the
history of my web browsing, javascript pop-up alerts have played a very small role.
-Peter

[Rgpublic (rgpublic)]

one important aspect of this bug hasn't been mentioned yet (as far as i can
see): i know *lots* of web developers who use "alert" as a quick hack to check
the contents of some javascript or php variable
Like
<?
$x="up"."down"; //<< Some calculations go here
?><script language="javascript">alert('<?=$x?>');<? //This is used to show $x
?>
Now, if you accidentally put this in a large/endless loop you are stuck.
This problem is far more common than some vicious website doing that so this
might raise the importance of this bug.

[Matthew Paul Thomas (mpt)]

This bug is invalid. Most window managers know how to make alerts window-modal
(on the Mac, app-modal) or system-modal, but the number of window managers which
know how to make an alert `content-modal' -- modal to some parts of the parent
window, but not others -- is approximately zero. Even if there are one or two
such window managers in existence, their lack of ubiquity makes it impossible to
prevent the DoS that way. That can only be done by approaches such as the one in
bug 61098.

[Jonasj-qio (jonasj-qio)]

Reopening. While the window manager might not know how to make a content-modal
dialog, we could just make the dialog modeless (to the window-manager) but cause
any click in the content area to focus it. Then the dialog would effectively be
content-modal.

[Malx (malx)]

Yet another 'joke' - for russian speaking users :(
http://fogi2000.narod.ru/photo.htm

A botton inside alert dialog, wich will redefining "alert() = void()" whould be
just fine :(

[Netdragon (netdragon)]

Bug 60150 is "Modal dialogs (alert, confirm, prompt) do not halt code
execution", which is not what the web page developer would expect. Not a dupe,
but related.

[Security-bugs (security-bugs)]

over to XP Apps to see if they have any ideas. This is a denial-of-service issue
and therefore not that high priority, but I'd be interested to hear about
possible solutions.

[Smanux (smanux)]

*** Bug 222125 has been marked as a duplicate of this bug. ***

[DavidPerry (d-perry)]

(In reply to comment #27)
> over to XP Apps to see if they have any ideas. This is a denial-of-service issue
> and therefore not that high priority, but I'd be interested to hear about
> possible solutions.

I'm still hopping through bugzilla breadcrumbs, so this may have been mentioned
elsewhere already. But I came across a situation in Safari 1.2.3 (v125.9) where
a non-selected tab suddenly got yellow "!" icon in it. When I selected the tab,
a modal dialog popped up. (I wasn't able to recreate the behaviour with an
alert in a non-selected tab, contrary to what I reported in bug 123908.)

What if you did something like that for content-modal dialogs? It doesn't
directly address the problem of freezing up the window when the currently
selected tab has an alert, but it does ensure the only modal dialogs the user
will see are for the tab they're currently viewing. Confusing situations like
the one described in bug 123908 comment #2 would be avoided.

[Jruderman (jruderman)]

*** Bug 237317 has been marked as a duplicate of this bug. ***

[Palaste (palaste)]

I want to add my wish to get this fixed too. I just visited some web page whose
author had an image map, and due to a rather spectacularly bad mistake in his
HTML code, he had made no less than *nineteen* rectangular areas, all
overlapping each other perfectly, over the image map, each with the "onclick"
attribute set to a Javascript alert.
Guess what this meant when I accidentally clicked on part of the image that
wasn't a link? Yes, you guessed it - I got nineteen consecutive Javascript
alerts, unable to do anything in between to stop them. Even closing the browser
window didn't help.
If the author would have been brain-dead enough to make a perpetual loop of
Javascript alerts I would have had to kill the entire browser process.

[Dveditz (dveditz)]

*** Bug 291474 has been marked as a duplicate of this bug. ***

[Super-egi (super-egi)]

There *is* an easy way to get out, all you have to do is press Ctrl + W and
click the OK button. There will probably be one more alert, and then the tab
will be closed.
However, I can't believe it's *that* hard to enable the user to disable
JavaScript while alert windows are open... just un-block the browser window (I'd
do it, but I'm too lazy to dig my way through the whole Firefox source code)

[Matti-mversen (matti-mversen)]

*** Bug 297404 has been marked as a duplicate of this bug. ***

[Gtdev (gtdev)]

The Web Developer Toolbar has a "Disable JavaScript" functionality. Would it be that hard to duplicate that for a modal dialog's originating context?

[Rflint-ryanflint (rflint-ryanflint)]

*** Bug 355904 has been marked as a duplicate of this bug. ***

[Jruderman (jruderman)]

*** Bug 361292 has been marked as a duplicate of this bug. ***

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software. This is already in progress and should be coming with Firefox 4. The upstream comments will soon be imported into Launchpad.
I'm going to mark it as Triaged and wait for upstream to work on this. Thanks for taking the time to make Ubuntu better! Please report any other issues you may find.

[Dolske (dolske)]

(In reply to comment #141)
> I just remembered something else - nsXULWindow::ShowModal pushes a null entry
> onto the JS context stack while the event loop spins

FTR: Talked with mrbkap today, confirmed this is actually redundant code... nsXPConnect::OnProcessNextEvent() also pushes a null context, so we'll still get it when spinning the event loop outselves.

[Gavin Sharp (gavin-sharp)]

(In reply to comment #149)
> I'd rather stop the script than having it continue to run in a closed window

Ah, I see. Throwing a catchable exception doesn't actually guarantee that it stops though, and it causes us to report exceptions for what will be common actions, like closing a tab with a prompt open. I guess we should probably deal with that in a followup by coming up with a way to throw an uncatchable/unreported exception from JS...

[Gavin Sharp (gavin-sharp)]

Comment on attachment 490029
Part 1 (main patch), v.5

>diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml

>+ <method name="getTabModalPromptBox">

>+ let promptBox = {
>+ appendPrompt : function(args, onCloseCallback) {

>+ let tab = self._getTabForContentWindow(browser.contentDocument.defaultView);

browser.contentWindow

>diff --git a/toolkit/components/prompts/content/tabprompts.xml b/toolkit/components/prompts/content/tabprompts.xml

>+ <binding id="tabmodalprompt">

>+ <description class="info.title" hidden="true" style="padding-bottom: 1em"/>

Padding should probably be in the theme? Though actually this element seems to be unused, since nothing ever unhides it... so we never show dialog titles. I guess it should just be removed then, and can be re-added if we do want to support showing titles?

>+ <hbox class="buttonContainer">
>+#ifdef XP_WIN

Flip this around and keep it #ifdef XP_UNIX as in dialog.xml to avoid changing OS/2 behavior :)

>+ <button class="button0" label="&okButton.label;" default="true"/>
>+ <button class="button0" label="&okButton.label;" default="true"/>

I think you should omit the default="true" here, otherwise you can end up with two buttons set as default when CommonDialog.jsm sets the attribute on a non-button0 button (without going through the _setDefaultButton logic in dialog.xml).

>+ <constructor>

>+ function getElement(class) {
>+ return document.getAnonymousElementByAttribute(binding, "class", class);

These should probably use anonid instead of class (I'm assuming most don't actually need a class for styling, but even if they do, they can have both specified).

>+ this.ui.button0.addEventListener("command", function() { binding.onButtonClick(0); }, false);

You could use this.ui.button0.addEventListener("command", this.onButtonClick.bind(this, 0), false);

>+ <method name="init">

>+ linkedTab.addEventListener("TabClose", this, false);
>+ window.addEventListener("unload", this, false);

Can you use an unload handler on this.args.domWindow instead of these two? Would avoid the need for linkedTab which simplifies things a bit.

>+ <method name="onKeyAction">

>+ if (action == "default") {
>+ let button = 0;
>+ if ("defaultButtonNum" in this.args)
>+ button = this.args.defaultButtonNum;
>+ if (!button.hasAttribute("default"))
>+ return;

This looks broken - defaultButtonNum.hasAttribute() throws (and indeed enter-to-accept seems broken). It looks like you can just remove it.

>+#ifdef XP_MACOSX
>+ <handler event="keypress" key="." modifiers="meta" phase="capturing"
>+ action="this.onKeyAction('cancel', event);"/>

I can't get this handler to do anything, not sure why.

>+#else
>+ <handler event="focus" phase="capturing">
>+ // Focus shift clears the default button.
>+ let bnum = 0;
>+ ...

[Dolske (dolske)]

Created attachment 491955
Part 1 (main patch), v.6

This is a small update to v.5, no review comments addressed yet.

* Adds a promptBox.listPrompts() method for tests
* Twiddles onPromptClose() and .promptActive -- my text fixes in bug 613403 exposed the interesting case of closing the prompt via the tabmodal-dialog-loaded notification... We were initializing .promptActive to true after the test closed the prompt, and onPromptClose() couldn't close the prompt because tabPrompt.appendPrompt() hadn't returned |newPrompt| yet!
* Fixed two little typos exposed by the tests in bug 613444.

[Dolske (dolske)]

(In reply to comment #153)

> >+ <description class="info.title" hidden="true" style="padding-bottom: 1em"/>
>
> Padding should probably be in the theme? Though actually this element seems to
> be unused, since nothing ever unhides it... so we never show dialog titles. I
> guess it should just be removed then, and can be re-added if we do want to
> support showing titles?

Removed the padding, I was thinking this could replace the <spacer/> that's in the sameish spot in commonDialog.xul. But I think that actually looks odd in commonDialog... Will follow a followup about tweaking these styles, already had some ideas.

I want to leave the always-hidden element in, though, so it's in the DOM as in commonDialog.xul (ie, I don't want to have to bother null checking it).

> You could use this.ui.button0.addEventListener("command",
> this.onButtonClick.bind(this, 0), false);

Yes! \o/

> >+ <method name="init">
>
> >+ linkedTab.addEventListener("TabClose", this, false);
> >+ window.addEventListener("unload", this, false);
>
> Can you use an unload handler on this.args.domWindow instead of these two?
> Would avoid the need for linkedTab which simplifies things a bit.

Doesn't seem to work; when closing a tab with a prompt I get an error about "component has no method named handleEvent", and although the tab goes away the extra event loop remains. So, leaving asis.

> >+ <method name="onKeyAction">
...
> This looks broken - defaultButtonNum.hasAttribute() throws (and indeed
> enter-to-accept seems broken). It looks like you can just remove it.

Oops. Must have broken this as some point. :/

I fixed it to work -- iirc the intention from dialog.xml was that the default keyboard action should only trigger the button when initial default button == current default button (default can shift on focus).

> >+#ifdef XP_MACOSX
> >+ <handler event="keypress" key="." modifiers="meta" phase="capturing"
> >+ action="this.onKeyAction('cancel', event);"/>
>
> I can't get this handler to do anything, not sure why.

Hmm. Doesn't seem to work with normal modal prompts anyway -- nor does it do anything in Safari. Just going to remove this.

> It might be nice in the future if tabprompts.xml shared more of the dialog API
> - for example, it could have the same defaultButton setter, and this code could
> always just take the first branch. Worth a followup bug, perhaps?

Eh, maybe, I don't feel strongly either way. I'm actually finding (at least in tests, so far) that using Dialog.ui.* is a very convenient way to get at things.

> >+ let topic = "common-dialog-loaded";
> >+ if (!xulDialog)
> >+ topic = "tabmodal-dialog-loaded";
>
> ...and so I wonder whether this shouldn't be something more generic -
> "dialog-loaded"? That might be too generic. Or maybe we shouldn't fire anything
> at all in the tabmodal case for now, and we can revisit when a need arises?

No, definitely want to fire something here -- it's the primary way for tests (and perhaps addons) to know when a new dialog is up and running, so they can twiddle/dismiss it.

I thought ...

[Dolske (dolske)]

(In reply to comment #153)

> >+ try {
> >+ // Get topmost window, in case we're in a frame.
> >+ var promptWin = domWin.top
>
> The fact that getChromeWindow() uses chromeEventHandler makes this unnecessary

Oops, it might not be needed for getChromeWindow, we end up calling getBrowserForDocument(), and that needs to know the topmost doc.

[Dolske (dolske)]

Created attachment 492034
Patch v.7

Updated with review comments.

[Dolske (dolske)]

Pushed to mozilla-central:

Part 1: http://hg.mozilla.org/mozilla-central/rev/b48b84055237
Part 2: http://hg.mozilla.org/mozilla-central/rev/1fc05b5edd02

Note that bug 598824 doesn't have a patch yet, so prompts triggered in background tabs won't do anything (behaviorally or visually) until you switch to that tab. We'll get that fixed ASAP.

Anyway -- Yay! Big thanks to the 165 users CC'd on this bug: Old bugs with lots of CC's are infamous for being hard to work in, because there can be lots of noise and off-topic debate. You've all been great -- very much appreciated! I <3 our community. And sorry for all the bugmail you've gotten over the past few weeks as this has neared completion. ;-)

Finally, just to answer a few likely-common questions:

1) This has landed in mozilla-central. If all goes well, it will first appear in tomorrow's nightly test build of Firefox 4 (http://nightly.mozilla.org). Firefox Beta 8 will be the first official release with this fix. This will not be backported to Firefox 3.6.

2) The only prompts this affects are the window.alert() / .confirm() / .prompt() calls triggered by pages. Things like HTTP Authentication, onbeforeunload messages, quit dialogs, etc are unchanged (ie, window-modal prompts). We'll look at fixing those later, probably after Firefox 4 to minimize risk.

3) This bug is closed now. If you find problems with the implementation, or have suggestions for more improvements, please file a NEW BUG, and mark it as blocking this one. CC me if you wish.

[Gavin Sharp (gavin-sharp)]

(In reply to comment #155)
> I fixed it to work -- iirc the intention from dialog.xml was that the default
> keyboard action should only trigger the button when initial default button ==
> current default button (default can shift on focus).

Dialog doesn't have any such special case, AFAICT. Enter always triggers the default action.

> > I can't get this handler to do anything, not sure why.
>
> Hmm. Doesn't seem to work with normal modal prompts anyway -- nor does it do
> anything in Safari. Just going to remove this.

It worked fine for me in normal modal prompts...

[Dolske (dolske)]

(In reply to comment #158)
> [...]

tl;dr: Fixed for Firefox 4. Not Firefox 3.6. File a NEW BUG for any issues or concerns.

Did I mention filing a NEW BUG? Great, thanks! :)

(file a new bug)

[Keegkey (keegkey)]

It fells much less responsive than in ff3.6.
On my machine P4 2.8GHz it take approximately 1-2sec to show up modal dialog.
Whereas in 3.6 is almost instantaneously. Any plans to improve this?
Otherwise great work, I like it very much.

[Dao (dao)]

(In reply to comment #161)
> It fells much less responsive than in ff3.6.
> On my machine P4 2.8GHz it take approximately 1-2sec to show up modal dialog.

Please file a bug. I suspect the blur effect is to blame.

[Surfer56 (surfer56)]

http://img257.imageshack.us/img257/8378/acid3test.png looks ugly

[Tim McCormack (phyzome)]

(In reply to comment #163)
> http://img257.imageshack.us/img257/8378/acid3test.png looks ugly

File a new bug, as the comments above yours instruct. (Check if one has already been filed for this first.)

[Geeknz (geeknz)]

Just got hit by this "solution", testing the nightly build (2010-11-21).

How are we to determine that a tab needs our attention this now that .alerts() and .confirms() no longer pop up over our current page?

Usage Scenario: Control system, accessed via Web Page, using Java Script to pop up critical notifications.

As far as I'm concerned, without some sort of notification system this bug is not Resolved Fixed.

[Geeknz (geeknz)]

Ack, sorry - missed the note regarding: https://bugzilla.mozilla.org/show_bug.cgi?id=598824. Will follow there.

[Yann Dìnendal (yannbreliere)]

I've noticed something, but I'm not sure if it is a bug: When a tab-modal alert is displayed, we can still interact with the content of the page by clicking on the url bar (for example), and the tabbing to a selectable item in the page. Is it intentional behaviour?

[Jk1700 (jk1700)]

@Yann - bug 613763

[Surfer56 (surfer56)]

I've created Bug 613937 , but I'm think Matthias don't understood what I meant.

[Mtanalin (mtanalin)]

There are two bugs compared with previous (window-modal) implementation (as for Windows version of Firefox 4):

1. only five lines are visible at once (unlimited in previous implementation). It makes sense to display more lines without need to scroll. Probably it makes sense to display all lines that fits into document client height (or only a bit fewer): for example, alert window would have height equal to 90% of client height or so);

2. alert text is not copyable (previous implementation has text selectable and therefore available to copy which is very useful and usable).

Are these need to be filed as a separate bugs?

[Jk1700 (jk1700)]

There are already filled bugs regarding these issues

[Dirkjan Ochtman (dirkjan-ochtman)]

You want to look at bug 613749 (1) and bug 613742 (2).

[Dolske (dolske)]

(In reply to comment #170)

> Are these need to be filed as a separate bugs?

I probably should have mentioned this back in comment 158 or comment 160...

If you have comments, issues, problems, etc, file a NEW BUG.

That's right! FILE A NEW BUG.

Thanks.

(file a new bug)

[1] You too, preed. new. bug. ;)

[Mtanalin (mtanalin)]

(In reply to comment #173)
Maybe it makes sense to introduce into Bugzilla some kind of "sticky" messages that would be easily noticeable without need to read hundreds of comments.

Anyway, appropriate bugs 613749 and 613742 already exist as stated in comment 172. Thanks for your attention.

[Faaborg (faaborg)]

>Maybe it makes sense to introduce into Bugzilla some kind of "sticky" messages
>that would be easily noticeable without need to read hundreds of comments.

that sounds like a new bug :)

[Matt McCutchen (matt-mattmccutchen)]

(In reply to comment #174)
> Maybe it makes sense to introduce into Bugzilla some kind of "sticky" messages
> that would be easily noticeable without need to read hundreds of comments.

That's what the status whiteboard is for. I have set it.

[Davemgarrett (davemgarrett)]

(In reply to comment #175)
> >Maybe it makes sense to introduce into Bugzilla some kind of "sticky" messages
> >that would be easily noticeable without need to read hundreds of comments.
>
> that sounds like a new bug :)

Actually, that sounds like a very old one -> bug 283695

[Privat-ni-po (privat-ni-po)]

At that point I want to very much thank Justin Dolske for his work! I very much appreciate this, window-modal dialogs for alert()s always were a great source of annoyance.

Thanks!

[Keegkey (keegkey)]

I've created performance related bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=614810

[Bijumaillist (bijumaillist)]

window.showModalDialog() should be tab modal (Bug 616839)

[Bmo-edmorley (bmo-edmorley)]

Believed to have caused regression bug 619644.

[Bugzilla-mozilla-org-khopis (bugzilla-mozilla-org-khopis)]

Adding deps from duplicate bug 616843

[Bugzilla-mozilla-org-khopis (bugzilla-mozilla-org-khopis)]

*** Bug 616843 has been marked as a duplicate of this bug. ***

[Fryn (fryn)]

*** Bug 520019 has been marked as a duplicate of this bug. ***

[I-gsalex (i-gsalex)]

The http access authentication windows are still window-modal.

[Matt McCutchen (matt-mattmccutchen)]

As per bug 562258 comment 31, this bug is specific to JavaScript alerts. Bug 616843 is the tracker for all other dialogs. I'm reverting the addition of the dependencies from bug 616843.

[Eshepherd (eshepherd)]

I've added this page talking about tab-modal prompts and how to use them from chrome (the code sample is in progress and will be added within the next hour or so).

In addition, the relevant XUL changes have been documented, I believe. If someone could review this and make sure it's accurate, I would appreciate it:

Updated (to include the getTabModalPromptBox method and tabmodalPromptShowing attribute):

https://developer.mozilla.org/en/XUL/tabbrowser

Updated (to cover the pref to return to the old style alerts):

https://developer.mozilla.org/en/Preferences/Mozilla_preferences_for_uber-geeks

New pages:

https://developer.mozilla.org/en/Using_tab-modal_prompts
https://developer.mozilla.org/en/XUL/Method/getTabModalPromptBox
https://developer.mozilla.org/en/XUL/Attribute/tabmodalPromptShowing
https://developer.mozilla.org/en/XUL/promptBox

[ashughes (anthony-s-hughes)]

Just noticed this very old in-litmus request. Canceling the request. Please re-nom if a test is still needed.

[Mtanalin (mtanalin)]

Thoughts aloud after two latest "changes": it would probably make sense to send notifications with a delay (instead of immediately) after the change, so that people were not disturbed with two consecutive notifications the second of which cancels the first one, so there is effectively NOTHING to notify about.

[Paul White (paulw2u)]

Upstream bug showing "RESOLVED FIXED" on 2010-11-20
Tested ok with Firefox 63
Closing by marking "Fix Released"