22049 - [split] javascript alert should not put up extermely modal dialog

Status: VERIFIED INVALID

(Core :: DOM: Core & HTML, defect, P3)

Description

[vroonhof]

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.

Comment 1

[Mike McCabe]

Reassigning to UE/UI owner.

Comment 2

[shuang (gone)]

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

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 4

[leger]

Sending ove to DOM folks to check out.

Comment 5

[vidur (gone)]

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.

Comment 6

[Prashant Desale]

Verified.

Comment 7

[vroonhof]

Attachment: A trivial java script modal box

Comment 8

[vroonhof]

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

Comment 9

[vidur (gone)]

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.

Comment 10

[Stuart Parmenter]

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.

Comment 11

[vidur (gone)]

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.

Comment 12

[Jesse Ruderman]

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

Comment 13

[Dan M]

  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?

Comment 14

[Jesse Ruderman]

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

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 16

[Matthew Mastracci]

Adding myself to CC: list.

Comment 17

[Matthew Mastracci]

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]".

[e-mail] 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.

Comment 18

[andreww]

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.

Comment 19

[joki (gone)]

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

Comment 20

[Matthew T (active 1999-2002)]

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

Comment 21

[Matthew T (active 1999-2002)]

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.

Comment 22

[Doug Turner (:dougt)]

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. 

Comment 23

[ekrock's old account (dead)]

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

Comment 24

[Andrew Thompson]

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

Comment 25

[Johnny Stenback (:jst)]

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.

Comment 26

[Peter Trudelle]

removing nsbeta3+ to get triage by current owners.

Comment 27

[Peter Trudelle]

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.

Comment 28

[ekrock's old account (dead)]

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!

Comment 29

[Jesse Ruderman]

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 (?)

Comment 30

[Jesse Ruderman]

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

Comment 31

[timeless]

verify: messy.