assuming bug 123908 is fixed on Mac OS X, that platform will have tab-modal alert messages. wouldn't be nice if other platforms had the same thing? To make this possible, I'd like to RFE a widget like Mac OS X's "sheets" which would be used for this purpose on apps which don't have native sheets. Heck, if you're making them from scratch, you could even make them *better* than Apple's sheets, and have them be attached to frames or tabs rather than just to windows. -matt

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

adding to summary to make bug easier to find. 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

-> future

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

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

m_mozilla (matt): I see this bug depends upon Bug 123908, but I'm really not convinced that a fix for this bug is impossible until 123908 is fixed. It looks to me like this bug and 123908 are siblings. Ask yourself if any proper dependency between them exists at all: couldn't you fix one even if you avoided fixing the other? This bug is an RFE, whereas 123908 seems to be more of a straight up bug (you filed both, so I presume you know). It seems just as logical to have 123908 dependant upon this bug, since fixing the general case would probably fix the OS-specific 123908 as well. Ultimately, I think either 1) 123908 and 123913 _are_ duplicates of 59314; or 2) 123908 and 59314 are duplicates of 123913. This is because I suppose there must be one really good way to fix all of them at once (such as the fix proposed here in 123913). On an unrelated point, consider adding Bug 121209 to block 123908 and/or 123913.

I think you're right, David. Bug 123908 tab-specific alerts are window-modal in MacOS X and should be tab-modal Bug 123913 (this bug) tab-specific alerts are app-modal and should be tab-modal (need "sheets" widgets on non-MacOSX) You *could* fix bug 123913 without fixing bug 123908, but at the time I'd indicated the dependancy, I wasn't thinking of any other ways to fix bug 123913. I'm not certain that any of the alternatives really do the job though, so I'm not certain that I should remove the dependancy. For example, take the idea of changing the backround color of a tab when that tab has an alert... That gives you a clear "it's this tab that has some alert pending" message, but once you click on that tab, suppose the javascript is going to give you a near-infinite stream of alerts. Are those alerts tab-modal (so you can ignore them and switch to another tab) or are they still window-modal (you can't change tabs because you're forced to keep dismissing alerts). It sounds like the other proposed fixes do half the job. They notify you that you have an alert in a tab-specific fashion, but once you look at the alert, you're not looking at a tab-modal alert. If anything, I can imagine that tab-modal alerts could be implemented first, and then users would have trouble knowing that their background tabs had pending alerts. *That's* the bug that the other solutions seem to fix in my mind, but that bug doesn't really exist yet. In my mind, things could be fixed in something like the following order: sheets on MacOS X would be replaced with window-modal XPI sheets window-modal XPI sheets would be made content-modal (tab-modal) XPI sheets would be applied to non MacOS X platforms some notification of "tab has pending sheet" would be created So, I think I'll leave the dependancy in place. If anyone thinks I'm off-track here, feel free to change it yourself. I'm not implementing any of this, and I'd expect that whomever does that will have a much clearer idea of what depends on what. :) I will make a note in bug 121209 about the discussion here though. -matt

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

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

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

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

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

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

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

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

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

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

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

Fixing this (for modal dialogs as well as modal alerts) would likely fix the latest Secunia report on Firefox, SA15489: http://secunia.com/advisories/15489/ This would be far better than adding the URL to the title, IMO, although that would be an adequate stop-gap measure.

This is hard to implement correctly. It requires that the underlying APIs are non-blocking, since you want other windows and tabs to function correctly while a given tab is "blocked" with a tab-modal alert. This would require significant re-architecture of many underlying systems.

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

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

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

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

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

I think this issue deserves a higher priority than "enhancement", since streams of dialog boxes are used in social-engineering attacks by malware pages to condition the user into clicking "yes" repeatedly until they encounter a software installation dialog, and then click "yes" on it as they have clicked on the previous ten dialog boxes... For the case of streams of alert boxes, would a "close this page"/"exit firefox"/"go to home page" or other form of "bail-out" button on alert boxes, clearly marked as distinct from the buttons generated by the alert box itself, be useful? An alternative approach might be to enforce a short delay between the display of successive modal dialogs, in order to allow the user a short pause in which to try to naviagate away from the page or exit the browser. It might be reasonable to gradually increase this delay as the number of successive dialog boxes increases, resetting it to zero as soon as any other form of user interaction occurs.

Talking about modal dialogs is just wrong. A web browser should treat the web page as the place for dialogs, so that they're naturally non-modal, tab-specific, and can be switched away from. (sheets in Mac OS X comes closest.)

I think we all agree that this is a good thing. But it's extremely hard to implement (the whole backend modality model has to change).

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

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

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

I agree that alert(), prompt() etc, should be tab-modal instead of window-modal. I also think that maybe they shouldn't be an OS widget(?) at all, but a display that's generated by Firefox inside the page, like the "Server not found" messages were revamped away from modal OS dialogs into special pages. That way it would be the same for every OS (Windows alert() dialogs look ugly), and would be tab-modal, too. This is a mock-up of what I think it should do: http://mysite.verizon.net/negatron/custom_alert.htm I'm not the best coder, and I just ripped off the alert() overloading from another site. Added some enhancements like "dimming" the background and using a chrome image. This could probably be made into a browser or greasemonkey script or something as a workaround, but I don't know enough to do that myself.

Personally, I think the simplest solution would be to delay the showing of the alert box until the tab containing its calling page receives focus.

(In reply to comment #33) > Personally, I think the simplest solution would be to delay the showing of the > alert box until the tab containing its calling page receives focus. That's just not possible without asynchronous up-call APIs (which Gecko, NSS etc don't have).

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

(In reply to comment #26) > I think this issue deserves a higher priority than "enhancement", since streams > of dialog boxes are used in social-engineering attacks by malware pages to > condition the user into clicking "yes" repeatedly until they encounter a > software installation dialog, and then click "yes" on it as they have clicked > on the previous ten dialog boxes... Not only that, but alert() in a loop hangs the browser because the dialog is modal. This not only could be used in an attack but also gets very annoying when you use it for debugging Javascripts. This bug (as any bug that forces the user to close the browser) should be marked Major if nothing else.

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

@Jon B: Cool! It doesn't look 100% perfect but it's a great proof of concept. Is it possibl to make a Firefox Extension that overloads the window.alert and window.promt functions for each webpage? That would be a nice workaround!

(In reply to comment #42) > Is it > possibl to make a Firefox Extension that overloads the window.alert and > window.promt functions for each webpage? That would be a nice workaround! I'm sure it's possible, as the page I attached is just a modified version of a script meant to overload those functions, but I don't know how to create an extension. I mentioned the same thing in https://bugzilla.mozilla.org/show_bug.cgi?id=123913#c32 :-)

How about using an nsIAlert to notify the user that there is a hidden dialog waiting? (i.e. growl)

Having an alert to notify the user that there is a hidden dialog waiting is good, but that should be an extension. Why not just colour the tab which has the alert and remove the possibility of that tab alert interrupting other tab activities? I do like the mock up alert suggested by Jon B, it's a bit fancy but it looks more modern, and less intrusive than the normal alert box.

Why in the world did I get this bug alert when I didn't sign up for it? Did I anger of one of the moderators by rebuking them? Revenge bugzilla spam eh?

_Please_, don't start a long discussion about the possible UI of this, unless you're going (and able) to fix the whole bug. The main problem with this is the modality of alert() and similar methods: the code that called alert() must be suspended until the user dismisses the alert. The call stack to the alert() call can contain both JS and native frames and it has to be preserved until the user dismisses the alert. The way it is implemented now is that when opening window-modal dialogs like alert() a new, nested event loop is spun in nsXULWindow::ShowModal until the dialog is dismissed (so the other windows are still functional). This causes various problems, which will become more visible, if this method is extended to work with tabs: For example, there's a bug about timeouts firing in a window that's supposed to be frozen by an alert(), other windows can modify the window that called alert() while the dialog is still open, successive alert() calls in different windows don't work well - try opening two windows, opening the javascript:alert("1.1");alert("1.2"); in the first window, then javascript:alert("2.1");alert("2.2"); in the second window, then dismissing the "1.1" alert. You'll see that the "1.2" alert will not appear, until you dismiss both alerts in the window #2. There are no obvious alternatives to the way it works right now - I don't know of a way to do continuations in a portable way in C++, and abusing threads to preserve the stack for each tab seems hard to do right. There are also comments on feasibility of this at http://blog.mozilla.com/faaborg/2007/03/06/would-you-like-to-redesign-notification-in-firefox-yes.-not-now.-never./ (see the comments) although I don't agree with some of them.

This might be harder to fix now that we support showModalDialog (bug 194404) in addition to alert/prompt/confirm :(

Is there any reason this can't be fixed with an extension? It's taking way too long otherwise. The code I found for my attachment hijacks the alert() function to display it as a div in the web page itself instead of an OS dialog. Surely an extension could be written that does the same thing for all modal dialogs.

Bug 520841 is an immediate security concern and this Bug should be moved from an "enhancement" to an "immediate" or more important level of concern. The presence of scriptable modal dialog boxes circumvents security issues. Please read https://bugzilla.mozilla.org/show_bug.cgi?id=520841

(In reply to comment #2) > 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... The summary, "Alerts should be content-modal, not window-modal", is more relevant than random comments.