197351 - window.open with window feature "modal" opens a modeless window instead of modal window

Status: RESOLVED INVALID

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

Description

[Hakan.Oezaslan]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312

Since Version 1.3 the "modal" feature of window.open does not work as expected
any more. A modeless window is opened instead of an modal window. This
functionality worked fine til version 1.2 of mozilla - I can't really understand
why this functionality disappeared.

Reproducible: Always

Steps to Reproduce:
1.window.open("http://localhost:8080/myApp/calendar.jsp","Calendar","resizable=yes,height=320,width=240,status=yes,toolbar=no,menubar=no,location=no,modal");
Actual Results:  
opens a modeless window

Expected Results:  
should open a modal window

Comment 1

[Hanspeter Niederstrasser]

Bug 180048 [suggest an override for modal in window.open]

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yep.  Unpriveleged script should not be able to open modal windows.  The fact
that this worked in 1.2.1 was a serious bug.

Comment 3

[Alfonso Martinez]

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

Comment 4

[jmcdaniel]

As the person who just submitted 197424. I apologize for the dup.  However I
have *huge* issue with the fundamental belief that this is a security violation.
 No doubt many or even MOST application developers will report this as a bug
(I'm tempted to resubmit it a few thousand times myself!)  Signing isn't an
option at many software shops which are writing front ends meant to be used by
3rd parties.  Having functionality only available to a signed script is almost
as damaging as its not existing at all.  A notable competitor has NO problem
making this functionality public.  As a long time user of Mozilla I have NEVER
ONCE encountered a script where a modal dialog was an issue.  (Has anyone using
said-other-browser?!) Just dismiss it!  Sorry to bother but if this is left I
have no idea how my company can continue to support Mozilla.  As my favorite
browser that is tragic news to me.  What public forum is there to strike down
this rather catastrophic decision?  This decision is compounded and made more
devastating by the fact that it is a HUGE behavioral change over 1.2.1.

Comment 5

[Michael Lefevre]

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

Comment 6

[Alessandro Fiorino]

I am working on a web application which relies heavily on modal windows, without
them I have to stop supporting Mozilla,leaving Internet Explorer as the only
supported client (this also stops using my application on non-Windows platforms!).
Why is a bug opening a modal window???

Comment 7

[jmcdaniel]

It occurs to me to add some comments as to the behavior of such dialogs in 1.3.
 There is zero security improvement over 1.2.1 that I can see.  Here's why:
"dialog" still works.  The dialog appears over the entire window.  You can still
get input past it, but must move it out of the way.  Notice it appears over the
whole window, not  only when the calling document is in view (is the active tab).
"chrome" is still allowed and makes the dialog look more "native"
the only affects that "modal" not working at all has is to:
1) cause code to flow past the open statement (the part that *MUST* change back
to the behavior of 1.2.1 in order for application developers to continue to
support your product!)
2) the dialog is truly no longer window modal.  If this is the issue make it
window modal only when the calling document is active.  I.e. make it a bit more
dialog modal than window modal.  Or leave this as is in 1.3, but just block the
calling JS thread.  (this, of course would lead to "loosing windows" so isn't a
very good idea either, so just fix it, please!!!!)

Furthermore if this is behavior that must stay (again, PLEASE say it isn't
so!!!) a security exception should be raised on the open statement & is not,
giving no programmatic feedback of the behavior change.

I am going to ask the security newsgroup to review this bug for lack of a better
forum to discuss it...

Comment 8

[Stefan Borggraefe]

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

Comment 9

[C Buenger]

our company put heavy resources to port our complete webclient of business-
application from ie to mozilla. now that it runs, mozilla is randomly changing 
behaviour in controls (see bug #175333) and browser that we have so much work 
fixing things and trying to simulate behaviour of a previous version of 
browser.
as developer, i can see no security-problem at all when javascript is able to 
open a modal window. modal windows are needed in modern windows-applications. 

what we develop now is not the standard click-and-view-websites but fully 
functional (nearly) smart-clients with heavy functionality and windows- or KDE-
-like design and functionality. these can't live without modal windows.

but there is a solution i developed for mozilla 1.1 and which i now have to 
include in our application again:
- just put an empty hidden iframe with style="cursor: wait; overflow: hidden; 
background: transparent" in body-tag on your document.
- before the call to window.open of modal window, "show" the iframe
- the transparent iframe "locks" input to page while modal window is visible
- when modal window is closed, "hide" the transparent iframe

(note: because of bug in cursor-showing in iputfields, make your transparent 
iframe "width=0px" when hiding and "width=100%" when showing)

this is just a try to "simulate" what everyone understands under "modal 
windows". the behaviour of mozilla 1.2.1 was much, much better and i would 
like to have this old behaviour back.

hope that helps

Comment 10

[Boris Zbarsky [:bzbarsky]]

Or you could actually request from the user the expanded priveleges your script
wants and then open modal windows to your heart's content if the user grants
those priveleges....

Please see bug 180048.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Phil Ringnalda (:philor)]

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

Comment 13

[Mike Connor [:mconnor]]

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

Comment 14

[Adam Guthrie]

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

Comment 15

[Andrew Schultz]

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