The URL stated above doesn't recognize Mozilla's DOM model and calls the javascritp alert function about 10 times. Each time this puts up a modal dialog box. Apart from the fact that modal dialogs are evil in themselves (especially when they can be generated by the webpage) this blocks up Mozilla and one can not use the menus and/or the Back button to get out.

Reassigning to UE/UI owner.

reassign it to general browser UI. It is not a UI design bug.

this is the proper behaviour of alert(). It is not our position to interfere with this behaviour. It is my opinion that alert() should spawn a completely modal dialog (as in 4.x).

Sending ove to DOM folks to check out.

I agree with Ben. The alerts are window modal and not application modal, so they aren't as evil as they could be. We'll stick with 4.x behavior.

Verified.

I am not sure how you guys "verified" this (nobody contacted me as far as I know). But - The current (M13) mozilla behaviour is NOT the same as in 4.x - The only way to get out of a site that loops popping up alert() boxes is to kill the browser. I hate it when the untrusted other side can block my browser. - At least on Unix, the dialog box is NOT window local. I load the attached file into Mozilla then I cannot do *anything* (No back button, No menus, no other windows) until I press OK. Could it be that this is some issue with "Modality" of dialag boxes on Unix in general, but was untill now dismissed as a minor UI issue. I am currently unable to check whether windows/mac behaves differently I reponed the bug. Jan

Again, if the alert dialog is window modal, it is the same behavior as 4.x. It is currently window modal on Windows. Handing it over to Pavlov, since the modality issue seems to be Unix only. Pavlov, send me mail if you think this is not your issue.

Hrmm.. Vidur, In 4.x on Linux, these alerts are not modal... I don't really like modal dialogs, but in this case I don't really care either way. You might want to reassign this to ben if you don't know.

Seems like we might need to figure out how to make them non-modal on Linux. Since this is non-critical, I'm moving it to a slightly later milestone. This will be revisited before shipping.

I don't think this bug should be limited to javascript alerts (and prompts). What if a page causes the browser to alert "can't connect to server" 30 times on one page (maliciously or otherwise)? As we've seen, making the windows non-modal does create problems (bug 25684), which I think can be stomped by limiting interaction with the main window to specific actions such as using the navigation toolbar or even just closing the window. Certain parts of the browser would be able to create totally modal windows, but this option would only be used sparingly. Since trying to create "almost modal" windows that act rationally on each platform is tricky (bug 21296), I'll suggest an alternate solution: place something on the dialog itself that allows the user to close both the dialog and the parent window. As above, internal code to netscape and perhaps signed javascript would be able to create totally modal dialogs. Since I don't code mozilla, I won't state that this is necessarily easier to code, but I don't see how it could be any more confusing to coders or to users than allowing the window to be closed by ordanary means. cc'ing danm, who recently killed non-modality (comments in bug 30633).

True, JS alerts aren't modal on Linux Navigator. That's not to say it has no modal windows at all: the auth dialog, for instance, is modal. I imagine that even alert windows need to be code modal, just not ui modal. The cross-platform Mozilla codebase currently knows about only two types of modality: modal or not. To make alerts behave as they do in Navigator we'd have to teach Mozilla about a third, pseudomodal type. Yargh. davidr8's suggestion would seem to necessitate adding a widget to each dialog. I think we can't force that on all window designers, though perhaps we could just do it to each of our own Common Dialogs. We'd be unique among all applications I can think of for doing such a thing, though. Alerts are completely modal on other platforms. So Linux Navigator users have a backdoor for escaping a stack of alerts that no one else has. Do we really have to do this in Mozilla?

> Do we really have to do this in Mozilla? not really. only if you want to be able to say, "not only is mozilla able to conform to more major standards than any other browser, but it is secure against all known attacks." cf bug 29346 (protect against malicious popup windows) and bug 30942 (protect against _unknown_ cpu-hogging attacks).

I'll refine my position: these windows should be modal to the content area - although I won't assert that they should be to the chrome (unless someone gives me a good reason :) They should be modal to the page content because otherwise, a user may be able to blur the dialog and interact with page content in a potentially harmful way - alert dialogs are normally spawned as part of a process, which assumes a certain flow of control, and allowing the user to perform other actions while in the midst of this flow may cause some pages to break. Failing the ability to make the alert modal to page content, I think the behaviour should remain as is.

Adding myself to CC: list.

ben: is it possible to use something along the lines of a glasspane *only* over the content area, such that the user can scroll through the content but can't send it events? This would allow the chrome and UI to stay responsive. If the user attempted to perform an operation that would invalidate the currently running Javascript (by hitting back, forward or stop), the UI could prompt with something like "This action will terminate script processing. [Terminate Script] [Continue]". davidr8@home.com had a good suggestion posted on bug #30942 to use a different status indicator for each state of mozilla. For instance, while content events were blocked due to script execution, the status indicator could display something other than a barber pole like it does for page loading.

Another case for "extremely" modal dialogs is in AIM. If you try to send and IM to someone offline, you get an alert saying something like "this person is offline". On mac the alert is completely modal, which works as it should, but on windows I can ignore the alert and try sending it over and over again. If the user somehow hadnt noticed the alert dialog, they could get confused pretty quickly. Alerts may be abused on some sites, but so are window.open(), window.onunload(), etc. etc. Having "almost modal" dialogs can cause flow of control to "break" when the developer assumes that it's modal when if fact it's not.

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

It's not reasonable to expect users to inspect the URL for every link they are about to visit (on an untrusted Web site) and make sure it's not javascript:while(1){alert("Gotcha")} . If it was reasonable, then Melissa, ILOVEYOU, etc would never have happened (because it would then also be reasonable to expect users to inspect the suffixes of e-mail attachments). On the other hand, we shouldn't make alert() non-modal, because (as described) that would break Web pages. And anything `semi-modal' would be inconsistent with the rest of the world. So, how about this: * the alert() dialog be given an enabled close box * the close box throw up a secondary dialog, asking `Do you want to stop all scripts in the current page?' (Stop) (Continue) * if `Stop' is chosen in this secondary dialog, scripts are stopped, the alert() dialog is closed, and the page contents are replaced with an error page (to prevent fiddling with the page) * `Ok' in an alert() dialog be renamed to `Continue' (to make it more likely that users will use the button, rather than the close box, to dismiss the alert).

Actually, strike that bit about replacing the page with an error page. Assuming you don't need to do that in other cases where scripts are stopped (like when Mozilla asks the user about an slow script or a script error), you don't need to do it here either.

Because of the use of nsCommonDialogs, or the use of the nsIPrompt service, this component can not be used for embedding. Adding the embedding keyword. How To Bring Up A Modal Dialog: You need to know what window you want to have modality against. This will be a nsIDOMWindow. Using a magic "hidden" window breaks modality and embedding application may not have this hack. One you have the parent DOMWindow, you simply: nsCOMPtr<nsIPrompt> prompter; aDOMWinow->GetPrompt(getter_AddRefs(prompter)); if (prompter) prompter-> Any other way that you try to bring up a dialog may not work in an embedding application. To reiterate, do not use the nsICommonDialogs interface -or- a nsIPrompt service if you want your component in a non-seamonkey app. I don't have a DOMWindow?! If you don't have a DOMWindow, you need to get one. Just about every place I saw that used the hidden window, could have used the real parent window with some work. There really is no place in the code where we should be displaying a modal dialog without knowing what parent window we are modal against. If you find a case where you don't have a top level window, lets talk.

Nominating nsbeta3. Severe problem for user experience; if a single window pops up an alert but is buried, whole browser seems to have hung & user must go searching for which window has the alert (if user even figures out that this is the problem).

> * the alert() dialog be given an enabled close box No, please don't! This is horribly confusing UI -> if a dialog has multiple buttons how can a user know which one the close box is equivalent to, if it is equivalent to any of them. I don't know that this evil window type (modal with close box) even exists on Mac OS. I see to recall the Apple's Java team had to beg the Human Toolkit group to add it because some (Windows) Java programers were creating modal dialogs with no buttons assuming there'd always be a close box to kill the dialog which were then imposssible to dismiss on the Mac! If Apple did build this in, it might not be is Mac OS 8.5 and it might not be public. Modal dialogs just shouldn't have close boxes, it confuses their meaning. If you need to have a "Kill This Script" button then have a "Kill this Script" button (with a confirm if needed) - then at least the user knows what it does, as opposed to overloading the meaning of the close box.

AFAIK the DOM code in mozilla does play nicely againt the rules dougt lays out above so there's not a whole lot we can do about this in the DOM code. Handing this over to danm who's in charge of the XP window code.

removing nsbeta3+ to get triage by current owners.

need info: This report doesn't seem coherent, need to know the exact defect that this is nominated nsbeta3 for, and what acceptable behavior would look be. As it is, this sounds like a lot of other bugs we don't have time to fix. Note that you could get into similar scenarios in 4.x, yet we shipped that.

Marking Future. Clearing [need info]. Taking the liberty of marking [nsbeta3-] because I think both engineering & mktg. agree on this. None of the issues in this report strike me as must-fixes for RTM. This bug report discussion has veered off in several directions. People's comments have been good and informative, but one of the Golden Rules of Bugzilla is One Issue Per Report. vroonhof, could you please split up this bug report into one separate bug report per issue so that each issue can be tracked individually? Many thanks for your help!

A few of these are reopened from being dups of this bug, and a few were already open. bug 28586 [rfe] Should use error page, not dialog, for inaccessible pages bug 41758 Linux problem where dialogs are app-modal instead of window-modal bug 59314 Alerts should be content-modal, not window-modal bug 61098 [rfe] a way to exit all currently active scripts Other bugs that seem related: bug 43390 Security check on modality breaks alerts/confirms (?) bug 60150 Modal dialogs don't prevent mouse events from going to parent (?)

Marking this bug invalid because it ended up getting too messy. If you've voted for this bug, you might want to consider moving your votes to one of the other bugs I just mentioned. If I missed any issues covered by this bug, please open a new bug and mention the bug number here. Also, someone who was experiencing bug 41758 (Linux problem where dialogs are app-modal instead of window-modal) should comment on that bug as to whether it's still happening. Thanks :)

verify: messy.