Last Comment Bug 180048 - suggest an override for modal in
: suggest an override for modal in
: qawanted
Product: SeaMonkey
Classification: Client Software
Component: Preferences (show other bugs)
: Trunk
: x86 Windows 95
: -- enhancement with 2 votes (vote)
: ---
Assigned To: Dan M
: Nobody; OK to take it and work on it
Depends on: 43390
  Show dependency treegraph
Reported: 2002-11-13 18:40 PST by Craig
Modified: 2006-08-17 12:43 PDT (History)
12 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

modality allowed only for windows opened from chrome, and for chrome windows (4.26 KB, patch)
2002-11-14 15:57 PST, Dan M
security-bugs: review+
jst: superreview+
Details | Diff | Splinter Review

Description Craig 2002-11-13 18:40:25 PST
User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20021014
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20021014

Mozilla has some excellent options for handling nasty sites, such as being able
to block opens of unrequested windows. However, there are times when a site
opens windows that the users wants to see but doesn't want to be held up by. The
site opens those windows with .... modal=1 to try to ensure that
users sit and wait while the content of the popup is loaded. However, users
might not consider this so crucial.

It would be good to have a subsidiary option such that if "open unrequested
windows" is allowed, the modal setting could be ignored.

Reproducible: Always

Steps to Reproduce:
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2002-11-13 19:43:41 PST
should untrusted content even be able to specify "modal"?  That seems wrong
Comment 2 timeless 2002-11-13 20:23:17 PST
it is wrong. make it stop :)
Comment 3 Daniel Veditz [:dveditz] 2002-11-13 21:12:03 PST
I confirm untrusted content can open a window modal. This is way wrong, and
neither Netscape 4.x nor IE allow you to do this.

This probably shouldn't be Ben, maybe danm or jag?
Comment 4 Andy Lyttle 2002-11-13 21:33:39 PST
Any documented standard anywhere that says "modal=" is a legit option?  If so,
we should optionally support it.
Comment 5 Daniel Veditz [:dveditz] 2002-11-13 21:36:30 PST
in nsWindowWatcher.cpp line 1325 a comment in rev 1.2 of that file (close to two
years ago) claims

  //XXX Temporarily removing this check to allow modal dialogs to be
  //raised from script.  A more complete security based fix is needed.

Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2002-11-13 21:39:09 PST
If there is a standard saying we should crash, should we support it?  This is
really no different (and no, there is no standard covering, period).
Comment 7 Daniel Veditz [:dveditz] 2002-11-13 22:08:38 PST
If there were really no standards about no one would be able to
use it. There may be no formal standards, but both Netscape and Microsoft
document it (not to mention hundreds of "learn web programming!" books) and
agree on a basic set of options.

We are obligated to support that basic set as much as any other standard we
support. We are not obligated to support things we invented for our own use e.g.
Comment 8 Andy Lyttle 2002-11-14 07:15:46 PST
Right, that's what I meant - if modal is just a Mozilla thing, we can take it
out.  If modal is documented, supported by other browsers, and being used on the
web (hopefully for good reasons, although I can't think of many), then yes, we
should support it, but make it optional (via Preferences) because it could be
abused (just like "open unrequested windows").

A standard saying we should crash is kind of silly - crashes are caused by bugs,
and are therefore not standardized across implementations, with some exceptions
from Redmond.
Comment 9 Dan M 2002-11-14 12:06:17 PST
"modal" was never intended to be exposed to untrusted script. See comment 5 and
bug 43390. It's almost flattering that obnoxious website authors have taken
special notice.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2002-11-14 12:14:23 PST
Hmm... Sounds like nsGlobalWindow::Open() should strip some stuff out of the
feature string for non-chrome windows....
Comment 11 Dan M 2002-11-14 15:55:06 PST
Exactly. Except for alerts, prompts and the like opened from content. That's
what bug 43390 is all about and that's why it started to get ugly and was punted
on two years ago.
Comment 12 Dan M 2002-11-14 15:57:10 PST
Created attachment 106289 [details] [diff] [review]
modality allowed only for windows opened from chrome, and for chrome windows

But (is this what you were talking about bz?) simpler than fixing the security
manager, does it make sense from a security perspective to allow modality for
chrome URLs? Johnny? Mitchell? This patch allows prompts thrown from content to
be modal because the URL is the dialog chrome URL, while normal"html...") from content is not allowed to be modal. Is it as easy
as this? What am I missing? In any case this is probably an improvement.
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2002-11-14 16:07:34 PST
Actually, what I was talking about is that we could fix this at the level
_before_ it gets into the windowwatcher.  That is, fix nsGlobalWindow::Open() to
strip out the "modal" part from the feature string if the caller is not chrome.
 prompt/alert/confirm do _not_ go through nsGlobalWindow::Open() and so would be

That said, I think the proposed solution is cleaner (and certainly simpler)
Comment 14 Johnny Stenback (:jst, 2002-11-15 13:39:42 PST
Comment on attachment 106289 [details] [diff] [review]
modality allowed only for windows opened from chrome, and for chrome windows

Comment 15 Mitchell Stoltz (not reading bugmail) 2002-11-19 18:08:24 PST
Comment on attachment 106289 [details] [diff] [review]
modality allowed only for windows opened from chrome, and for chrome windows

Comment 16 Dan M 2002-11-25 11:49:53 PST
Override be damned, untrusted client script should not be able to open modal
windows at all. And unless I goofed, can no longer. There is some worry that
windows which _should_ be modal (alerts) will be hurt. However the patch has
been in the trunk since last Wednesday, Nov 20th. I haven't heard any
complaints; seems good.
Comment 17 Mike Kaply [:mkaply] 2003-03-31 08:00:41 PST
There's a contradiction here:

"modality allowed only for windows opened from chrome, and for chrome windows"

"untrusted client script should not be able to open modal windows at all"

Which is it?

What preference can I add to make content trusted so that it can make modal windows?

It's pretty hard to write web based applications if you can't do modal dialogs.
Comment 18 Andy Lyttle 2003-03-31 08:22:01 PST
I think the idea is that chrome, which is part of the browser package, is
trusted and can open modal dialogs, while anything else (e.g. a web page on the
Internet) is untrusted and can't.  I'd suggest filing an RFE for a "trusted
sites" list containing domains where you want modal dialogs to be allowed on.

Note that if you're developing web applications that require modal dialogs,
you'll have to require your clients to enable this, since it won't be on by
default in Mozilla.  If this is for internal use, your IT dept can implement it
in their standard image so users don't have to change anything.
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2003-03-31 08:34:35 PST
mkaply, does requesting UniversalBrowserWrite not work?
Comment 20 Mike Kaply [:mkaply] 2003-03-31 08:45:11 PST
bz: Works great. Thanks!
Comment 21 Onur Ozorhan 2006-08-16 06:25:07 PDT
(In reply to comment #20)
> bz: Works great. Thanks!

so is there any other way of opening modal windows apart from enabling UniversalBrowserWrite? it seems that there's not. however sites on the internet/lan also can't request this unless they are using signed scripts.

so basically I need a 695$ security certificate and I have to bear with updating jar files everytime I modify my script just to show a modal window, is that so?
Comment 22 Daniel Veditz [:dveditz] 2006-08-17 12:43:03 PDT
Asking for help in a bug closed three years ago isn't generally productive. Please see for links to technical newsgroups.

Note You need to log in before you can comment on or make changes to this bug.