Tom Hessman Reporter
	Description • 19 years ago

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050513 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050513 Firefox/1.0+

Modal dialogs, spawned either by Firefox itself (such as SSL warnings) or by
JavaScript in web pages calling window.alert(), are resizable by grabbing the
grippy (in Mac OS X) or the window edges (in Windows) and dragging.  These types
of dialog boxes should not be resizable, but they are when
dom.disable_window_open_feature.resizable is set to true.

Reproducible: Always

Steps to Reproduce:
1. Set security.warn_entering_secure to true
2. Set dom.disable_window_open_feature.resizable to true
3. Open a new tab and go to https://bugzilla.mozilla.org
4. Grab the bottom right corner of the security warning and attempt to resize it

Actual Results:  
The dialog box is able to be resized, allowing you to make it really big, or so
small that the OK button is no longer visible.

Expected Results:  
The dialog box should not be resizable, regardless of the value of
dom.disable_window_open_feature.resizable.

I verified this bug in both Firefox and Seamonkey (both Classic and Modern), on
the trunk and the latest release versions (1.0.4 and 1.7.8 respectively), on
both Mac OS X and Windows.  This bug is more obvious on Mac OS X since it places
a grippy on the bottom right corner.  The dialogs are only resizable when
dom.disable_window_open_feature.resizable is set to true; when it is false they
behave as they should.

The above steps reproduce this bug using a dialog box spawned by Firefox.  I
will attach a testcase which uses a JavaScript alert() windnow.

I apologize if this bug was filed under the wrong component, but it was unclear
whether it should be filed as a JavaScript bug, a DOM bug, or something else...

	Tom Hessman Reporter
	Comment 1 • 19 years ago

This testcase uses JavaScript's window.alert() function to open a modal dialog
box.  Click the button to spawn the dialog box, and if
dom.disable_window_open_feature.resizable is true then it will be resizable.

	Bob Clary [:bc] (inactive)
	Comment 2 • 19 years ago

Not a js engine issue. Over to XP Toolkit/Widgets?

	neil@parkwaycc.co.uk
	Comment 3 • 19 years ago

Mozilla doesn't recognise these alerts as chrome because a) content script is on
the JS stack and b) their parent is the content window. We could tweak nsIPrompt
to parent them on the chrome window (while still dispatching
DOMWillOpenModalDialog etc), or we could find some other way of identifying
windows opened by nsIPrompt as chrome.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 4 • 19 years ago

We could push a null nsJSContext on the stack while opening the alert...  jst,
what do you think?

Over to a component where it might get noticed.

	Gérard Talbot
	Comment 5 • 19 years ago

I tried the steps to reproduce and the testcase and I got the expected results
in both instances and for both Seamonkey 1.1a rv: 1.9a1 build 2005100105 and
Firefox 1.4.1 rv: 1.8b5 build 20051001 under XP Pro SP2 here.

WFM

	Tom Hessman Reporter
	Comment 6 • 19 years ago

I re-tested my testcases, on both Mac OS X and Windows XP SP2, using Firefox
1.4.1 rv: 1.8b5 build 20051001, and this bug still exists.  I was still able to
resize the alert boxes.

	Gérard Talbot
	Comment 7 • 18 years ago

Tom, is the bug still happening? With steps to reproduce? With provided testcase? Just asking..

	Tom Hessman Reporter
	Comment 8 • 18 years ago

Yes, I can still reproduce this bug using both the "Steps to Reproduce" and the provided testcase, using Firefox 2.0 RC2 (2006-10-03) on Mac OS X and Windows 2000, as well as Firefox 1.5.0.7 and today's trunk build (Minefield) on Windows 2000.  It still works exactly as I described...it's possible to grab the edges of the dialog on Windows or the grippy in the bottom right on Mac OS X and resize these dialog windows when dom.disable_window_open_feature.resizable is set to true.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 9 • 18 years ago

So the problem is basically that the DOM prefs apply unless the URI being opened is chrome _and_ the parent is chrome.

In this case, the parent is, of course, the web page.

I think the right fix is to either remove the aHasChromeParent check or to allow non-chrome parents posing a dialog to use whatever features they want, since normal web pages cannot pose arbitrary dialogs.

	Benjamin Smedberg
	Comment 11 • 18 years ago

Comment on attachment 242417 [details] [diff] [review]
Like so

I suppose... though if we ever implement content opening modal dialogs, we may have to revisit this.

	Johnny Stenback (:jst)
	Comment 12 • 18 years ago

Comment on attachment 242417 [details] [diff] [review]
Like so

sr=jst

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 13 • 18 years ago

Fixed on trunk.

	Tom Hessman Reporter
	Comment 14 • 18 years ago

I can confirm that this bug seems to be fixed using the 2006-10-30 trunk build on Windows 2000, using my testcases.  Haven't tried Mac OS X yet...

	Dão Gottwald [:dao]
	Comment 15 • 17 years ago

Did this regress? I can resize alerts with the latest trunk nightly on Win XP with dom.disable_window_open_feature.resizable set to true.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 16 • 17 years ago

See comment 11.  Looks like we did just that, and regressed this with bug 393900.  Can you get a bug filed on that?