Closed Bug 360312 Opened 18 years ago Closed 18 years ago

the "modal=yes" option to window.open from untrusted script no longer causes the new window to be dependent on the opener (always-on-top)

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Version:
1.8 Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mitch, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

Modal window test
(deleted), text/html
Details
An example of as close to a "true" modal as I can get in Firefox
(deleted), text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 I have an AJAX application that HAS to use modal dialogs. I set the "modal=yes" property on the window which worked in Firefox 1.5 but does not work in 2.0. Reproducible: Always Steps to Reproduce: 1. Using my test, click the button. 2. After the window has opened, click on the opener window 3. In Firefox 1.5 the window stays on top. In 2.0, the window disappears. Actual Results: The window does not stay on top. Expected Results: The window should stay on top. <html> <head> <script> function open_modal() { var open_win = window.open("http://www.getfirefox.com", "modal_window", "width=300,height=200,modal=yes"); } </script> </head> <body> <input type="button" value="Open Modal Window" onClick="open_modal()"> </body> </html>
Attached file Modal window test (deleted) —
Comment on attachment 245272 [details] Modal window test Try this in Firefox 1.5 and Firefox 2.0
Ah, the window does indeed "stay on top", but it isn't "modal" by the usual meaning of the word; you can still interact with the opener window.
Keywords: regression
(In reply to comment #3) > Ah, the window does indeed "stay on top", but it isn't "modal" by the usual > meaning of the word; you can still interact with the opener window. > You're right, it's not a "true" modal. But I was setting mouse event listeners on the opener window so that if the user did anything on the opener window, it would give focus back to the modal window. This method worked fine in 1.5. But it doesn't work at all in 2.0.
Do those same techniques work in Fx2, if you add a window.raise() or whatever to the mix? (Resummarizing.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: the "modal=yes" option worked in Firefox 1.5 but boes not work in 2.0 → the "modal=yes" option kept window on top in Firefox 1.5 but does not in 2.0
This looks to me like a regression from bug 344257. We no longer allow the "dependant" flag to be set on non-chrome windows. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp&rev=1.129&mark=1500-1503#1478
Assignee: nobody → general
Blocks: 344257
Component: General → DOM
Product: Firefox → Core
QA Contact: general → ian
Summary: the "modal=yes" option kept window on top in Firefox 1.5 but does not in 2.0 → the "modal=yes" option to window.open no longer causes the new window to be dependent (always-on-top) on the opener
Version: unspecified → 1.8 Branch
OS: Windows XP → All
Hardware: PC → All
Summary: the "modal=yes" option to window.open no longer causes the new window to be dependent (always-on-top) on the opener → the "modal=yes" option to window.open no longer causes the new window to be dependent on the opener (always-on-top)
Flags: in-testsuite?
Summary: the "modal=yes" option to window.open no longer causes the new window to be dependent on the opener (always-on-top) → the "modal=yes" option to window.open from untrusted script no longer causes the new window to be dependent on the opener (always-on-top)
Well..... wait a sec. See https://bugzilla.mozilla.org/show_bug.cgi?id=344257#c3 last paragraph. The dependant flag shouldn't have been doing anything here anyway. So what exactly is the deal?
This is an example of what I was trying to do. This is as "true" of a modal as I could get in Firefox. This again works in 1.5 but not 2.0.
So... What happened is that for Firefox 2.0 the "do not allow sites to raise or lower windows" preference defaults to true. See bug 307407. So that window.focus() call does not raise the window.
Blocks: 307407
(In reply to comment #9) > So... What happened is that for Firefox 2.0 the "do not allow sites to raise or > lower windows" preference defaults to true. See bug 307407. So that > window.focus() call does not raise the window. > Ok, I see that, I marked the "let script raise and lower windows" checkbox and it made my modal window work. Is that option always going to default to false? I can't always assume my users are going to check the box.
(In reply to comment #7) > Well..... wait a sec. See > https://bugzilla.mozilla.org/show_bug.cgi?id=344257#c3 last paragraph. The > dependant flag shouldn't have been doing anything here anyway. So what exactly > is the deal? It seems that the last paragraph of bug 344257 comment 3 is incorrect. I haven't really looked into it, but it seems like the setting of parent at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/appshell/src/nsXULWindow.cpp&rev=1.171#1760 is what the old behavior depended on. (In reply to comment #10) > Is that option always going to default to false? I can't always assume my users > are going to check the box. The default was changed intentionally, if that's what you mean. If we think that disallowing window.open(..., "modal=yes") is the right thing to do by default (bug 180048), then allowing web developers to achieve the same effect using window.focus() probably isn't desired. Not to mention the other annoying uses of window.focus().
This is similar to bug 357814 in that the web site was using a hack to create a "modal" window and it no longer works by default in Firefox 2.
> I have an AJAX application that HAS to use modal dialogs. It might help your case (or, more likely, help us suggest an alternate solution) if you explained why your site uses modal dialogs.
Actually, this isn't quite like bug 357814. The focus() part is not the part under discussion. The question is whether using the "modal" feature for a content window should make it dependent (but not modal), which keeps it in front of the parent window on Mac and Windows (but possibly not Linux). That's the behavior we had in Gecko 1.8.0.... And arguably we shouldn't be changing it in Gecko 1.8.1. Very arguably. I should note that for unsized windows we should indeed ignore the flag (or just back out bug 344257 and accept that they will not be opened in tabs).
Although I suppose bug 357814 lumped the "modal" and "dependent" stuff into the report too... <sigh>.
(In reply to comment #13) > > I have an AJAX application that HAS to use modal dialogs. > > It might help your case (or, more likely, help us suggest an alternate > solution) if you explained why your site uses modal dialogs. > It's not just a web site... I have a very large AJAX application. When I popup a chooser window, I can't have users interacting with the opener window until the popup window is closed. It's the exact same reason why all applications, or programs, use modal windows. So what do you suggest I use as an "alternate solution".
Dup of bug 354123?
Should decide the exact behavior of this stuff and finally DOCUMENT it for 1.9, imo.
Flags: blocking1.9?
The only way we're going to support modal HTML dialogs is if we add support for IE's modal HTML dialogs (I forget the API, but there's a bug on file already). This bug is IMO WONTFIX. Marking as such. Please file a new bug on fixing documentation etc for anything related to this.
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: blocking1.9? → blocking1.9-
Resolution: --- → WONTFIX
FWIW, bug 194404 (add showModalDialog) was just fixed.
I believe this bug also got fixed in the process, for what it's worth.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: