Closed Bug 214867 Opened 18 years ago Closed 1 year ago
Don't let web pages use dependent=yes in window
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 The window showing the past and current graph of the value of the futures items doesn't show up on the taskbar Reproducible: Always Steps to Reproduce: 1. Go to tradesports.com 2. Click on the top future under "today's highlights" 3. Click on the top link that is below "contract" and right of the tradesports logo Actual Results: A window opened that showed information about that future went up but it wasn't shown on the taskbar. If I tried to minimize it, it looked like when a window inside AOL was minimized. I could move around the minimized window. Expected Results: Mozilla should have shown the window on the taskbar and it should have acted like a typical window when minimized.
Assignee: blake → dom_bugs
Status: UNCONFIRMED → NEW
Component: General → DOM Level 0
Ever confirmed: true
Product: Firebird → Browser
QA Contact: asa → ashishbhatt
Summary: Tradesports graph window doesn't show up on taskbar → window.open() can use dependent=yes (window doesn't show up on taskbar)
Version: unspecified → Trunk
In addition to keeping windows off of the taskbar, dependent=yes makes the window close if you close its opener. That's probably why tradesports used it.
Just for your info, MSIE supports showModelessDialog() which is the closest thing to a Mozilla dependent window. A ModelessDialog window in MSIE will not be shown in the statusbar, will close of its opener closes but will not be minimizable. I'm not sure this is a bug; an enhancement, maybe. If dependent child windows were not shown in the statusbar in NS 4.x (which I have not verified), then why should this be considered a bug? Just asking.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
Gerard, it's useful to know that dependent=yes is documented, but that doesn't mean Mozilla/Firefox should support it.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
A dependent child window has 3 consequences, implies 3 behaviors w.r.t. its parent window: 1- it will close if its parent closes 2- it will be minimized on the Windows task bar if its parent is minimized 3- it will be/stay/remain on top of, in front of its parent That's what the documentation says for NS 4 and Mozilla-based browsers. That's also what empirical testings and objective verifications report. That's how dependent was first introduced and was implemented. As far as I'm concerned, this bug is INVALID per all definitions. I tried to carefully substantiate all this and I'm convinced a majority of reasonable people would reach the same conclusion I reached. Now, if Mozilla/Firefox should not support dependent, then the normal thing to do is to write a summary accordingly and to identify the bug as a enhancement request, not as a normal bug. Same thing with any/all other window features (modal, dialog, chrome, etc.) which you may think that Mozilla/Firefox should not support and which we all know are very constraining on users, reducing usability and/or accessibility (and often poorly used or unjustifyingly used by authors). Personally, I would never have implemented dependent, modal, dialog, chrome, scrollbars, resizable, menubar, status as windowFeatures in the window.open() method. The less bugfiles are maintained, updated accordingly, the more these eventually lead to waste of time of good-willing volunteers, to misunderstandings, counter-productive inconsequences and frustrations. 6 months ago, I asked in this bugfile one single question and no one answered me.
Severity: normal → enhancement
Summary: window.open() can use dependent=yes (window doesn't show up on taskbar) → Don't let web pages use dependent=yes in window.open()
Has this been fixed? See bug 354123.
Dependent windows are modal windows of a special kind, with a particular behavior: they are nevertheless modal windows. What changed is that modal windows are no longer possible without granted UniversalBrowserWrite privileges: bug 180048 is decisive here.
"'modal' was never intended to be exposed to untrusted script." Dan M, bug 180048 comment #9 "'dependent=1' should not work for untrusted content." B. Zbarsky, bug 194404 comment #4 There are other interesting comments in bug 194404
I just figured there is no preference in about:config to disable this option. I'd like to have e.g. "dom.disable_window_open_feature.dependent" to be able to disallow this option. Should I file separate enhancement request to this effect?
I appear to be swimming upstream, but I really like/need the dependent window feature for an application I am recoding. The login screen opens a menu window and clicking on the menu options opens dependent windows. It is important that closing the menu window also close all the dependent windows for a clean logout
Assignee: general → nobody
QA Contact: ashshbhatt → general
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
Status: REOPENED → RESOLVED
Closed: 17 years ago → 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.