Popup window chrome appears when no options set




17 years ago
6 months ago


(Reporter: undeconstructed, Unassigned)


Windows 98

Firefox Tracking Flags

(Not tracked)



(2 attachments)



17 years ago
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

Comment 1

17 years ago
Created attachment 83207 [details]
Various tests of popup options

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

Comment 2

17 years ago
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>
Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
Ever confirmed: true
QA Contact: pschwartau → desale
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.
Created attachment 83220 [details] [diff] [review]
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

17 years ago
Please run this through danm before proceeding any further. I thought this was
the intended behavior (memories of old bug comments...)
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 :-)
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Assignee: general → nobody
QA Contact: desale → general

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
You need to log in before you can comment on or make changes to this bug.