143723 - Popup window chrome appears when no options set

Status: NEW

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

Description

[Phil Housley]

Creating a javascript popup with no options will cause the window to appear with
all the all chrome attached.  However, if you call window.open with no _actual_
options, ie with a meaningless string, no chrome will appear (ignoring the fact
that minimised toolbars will display (bug 57022 has been set to future for a
year and a half incidentally).

I will attach a quick test of various different option strings.

I apologise if this is standard, but I can't find any recent specs for this
function.

Comment 1

[Phil Housley]

Attachment: Various tests of popup options

Forgot to mention that this is happening on RC2 (2002051006).

Comment 2

[Phil Schwartau]

Browser, not engine ---> DOM Level 0

Here is the testcase:

  <button onclick="window.open('', '', '')">No options</button>
  <button onclick="window.open('', '', 'location=yes')">location=yes</button>
  <button onclick="window.open('', '', 'location=no')">location=no</button>
  <button onclick="window.open('', '', 'menubar=yes')">menubar=yes</button>
  <button onclick="window.open('', '', 'menubar=no')">menubar=no</button>
  <button onclick="window.open('', '', 'thisstring')">thisstring</button>

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

I thought this was the intended behaviour, but I tried on NS4x and passing an
emptry string for the third argument to window.open will also open a window with
no features...

In any case, I have a fix for this.

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Proposed patch v1.0

If we get passed three arguments, also check to see if the third argument is
empty.	If it is, then give it a dummy argument so that we don't think that
there really was no argument specified.  This allows window.open() to work
still with all features, but addresses the issue in this bug.

Comment 5

[Fabian Guisset]

Please run this through danm before proceeding any further. I thought this was
the intended behavior (memories of old bug comments...)

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

Yeah, I thought it was intended too... (see my comment #3).  The fix is simple
though if we want to take it.  If not, no harm done :-)

Comment 7

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 8

[Firefox Bug Husbandry Bot]

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.