53496 - no urlbar when using window.open and only 'location=yes'

Status: VERIFIED FIXED

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

Description

[djoham]

Mozilla build ID: 2000091312
Description:
Using the following code:

var x;
window.open("http://www.foo.com",x, "toolbar=yes");

will cause mozilla to open up a new window (as desired) but the new window's URL
bar will not be present. The rest of the toolbar (back, forward, et. al) will be
there, but the URL bar is gone.

This happens all the time.

Steps to reproduce:
Open up test case and click on the button. Note that the new window will come
up, but will not have a URL bar.

Actual Results:
The new window opens, but no URL bar is present.

Expected Results:
I would expect the URL bar to show up and be typeable.

Additional information:

1) M17 did *not* have this problem
2) Same result with both Classic and Modern skins


I am ranking this bug major for a couple of reasons:
1) The default value for toolbar seems to be no. If you used the following code:
   window.open("http://www.foo.com", x, "width=300")
   you will get a window with no toolbar. In order to get the toolbar,
   you need to add "toolbar=yes". This leads us to the problem in the bug.
   At this time, there is *no* way to open a window with any options and
   have a URL bar.

2) Omigosh. Can you imagine what would happen if some marketing person found out
about this? Open windows that you can't leave! Kewl!

I've also attached a screenshot.

Comment 1

[djoham]

Attachment: test case

Comment 2

[djoham]

Attachment: screenshot

Comment 3

[cosmodog]

Attachment: badly nested html tables, 4 radio buttons, a text area, and some java script

Comment 4

[cosmodog]

sorry for the above comment:
==
 badly nested html tables, 4 radio buttons, a text area, and some java script
==
I was trying to attach a test to a different bug.

Comment 5

[Luis Villa]

Confirming. No idea whose bug it should be, but it is real.

Comment 6

[Johnny Stenback (:jst)]

Yup, it's real, I see this too (on linux), I don't know who this would belong to
either, maybe hyatt knows?

Comment 7

[John Morrison]

First, very nice bug report and testcase. But, um, do you get a urlbar 
(a.k.a. location) in Nav4.x unless you say 'location=yes'? :-]

Because of the conjoined toolbar and location in mozilla's xul description, 
these are no longer quite the distinct entities that they once were. However, 
if you say 'toolbar=yes,location=yes', then you get both. 

It is somewhat of a defect that if you only say 'location=yes', you get 
nothing, although I'm not sure how you would provide location without the
rest of the wrapping. And for that, we can keep the bug (unless danm punts).

-> danm, Future (but not a major loss of function, since 'location=yes' is 
required to get a location bar (although 'toolbar=yes,location=yes' is not
documented as required))

Comment 8

[John Morrison]

Attachment: extended testcase with combinations that work

Comment 9

[John Morrison]

desale -- you should add this to the release notes for RTM, since it is a point 
of confusion, departure from past behaviour.

(Changing summary from "no urlbar when using window.open and 'toolbar=yes'")

Comment 10

[djoham]

John,

Well, I learn something new every day. I wasn't aware of the location attribute. 
Thanks for the explanation.  

David

Comment 11

[Dan M]

  John's analysis is spot-on, as usual. This is a known problem, and it's a bit 
of a poser. It stems from the fact that the exact layout of the browser's UI is 
unknown to the code that implements chrome visibility. Mozilla's and Netscape's 
current XUL UI definition for the browser happens to make the location bar and 
toolbar not independent like they were in Navigator 4, by placing one inside the 
other. It doesn't have to be that way, and could be changed with trivial effort 
at any time.
  And of course if you mention anything at all in the features parameter 
("toolbar=yes"), then every unmentioned feature is turned off. That's a 
"standard."
  A general solution to this problem -- and anything less than general is 
pointless because of the fluidity of a UI defined in XML -- is inefficient and 
kind of ugly. I don't foresee this becoming an issue common or troublesome enough 
to warrant the trouble, so I'm conking this bug in the head.

Comment 12

[Dan M]

*** Bug 55324 has been marked as a duplicate of this bug. ***

Comment 13

[Dan M]

*** Bug 66670 has been marked as a duplicate of this bug. ***

Comment 14

[Prashant Desale]

Marking Verified WONTFIX according to danm's comments.

Comment 15

[Jesse Ruderman]

*** Bug 79380 has been marked as a duplicate of this bug. ***

Comment 16

[Jesse Ruderman]

IMO, location=yes should force toolbar=yes until the navigation toolbar and 
location bar are separated (49543).  If a script asks for a location bar, 
there's usually a good reason.

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 99046 has been marked as a duplicate of this bug. ***

Comment 18

[Dan M]

You know, when I closed this bug "won't fix" I was thinking C++. It could 
reasonably be fixed in CSS. It can't be fixed in C++ because the generic 
interface-building back-end code can't be special-cased for the current Mozilla 
front-end structure, in which the location bar happens to be inside the toolbar. 
But it makes sense to fix this in a front-end specific place, where knowledge of 
the chrome structure lives.

In light of the duplicate bugs splattering against this one's windshield, I'm 
reopening it and -- heh -- reassigning it to the Apps team. My suggested path to 
fixing this would more realistically find a champion there.

Comment 19

[Dan M]

The following patch to Windows' classic skin navigator CSS kind of fixes this 
problem (a complete fix would of course necessitate similar changes across 
platforms and skins).

Index: themes/classic/navigator/win/navigator.css
===================================================================
RCS file: /cvsroot/mozilla/themes/classic/navigator/win/navigator.css,v
retrieving revision 1.33
diff -u -r1.33 navigator.css
--- navigator.css	2001/08/04 06:19:56	1.33
+++ navigator.css	2001/09/13 01:27:42
@@ -6,6 +6,14 @@
 @import url(chrome://navigator/skin/personalToolbar.css);
 @import url(chrome://communicator/skin/sidebar/sidebar.css);
 
+/* this skin puts the location bar inside the toolbar */
+window[chromehidden~="toolbar"] .chromeclass-toolbar {
+  display: block;
+}
+window[chromehidden~="toolbar"][chromehidden~="location"] .chromeclass-toolbar 
{
+  display: none;
+}
+
 /********** resource bundle binding **********/
 
 #resource_bundle_navigator

This is just a suggestion; a real Apps person could probably come up with a 
better solution.

Comment 20

[Peter Trudelle]

->ben, p3/096

Comment 21

[Dan M]

*** Bug 96147 has been marked as a duplicate of this bug. ***

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

I think you're supposed to say something else to get the location bar. At least
that's the way it is in IE, and as I expect it'd have been in 4.x. There are
cases when you want just the navigatino toolbar buttons and not provide any
urlbar for navigation. You could argue that the groove around the URLBar &
URLBar related widgets shouldn't show up when location=yes or whatever it's
called isn't specified. 

Comment 23

[Dan M]

toolbar but no location bar is easy: open('', '', 'toolbar'). location bar is
harder: open('', '', 'toolbar,location'). That's just a consequence of our
particular UI, however. In 4.x, open('', '', 'location') sufficed. The failure
of what sufficed in 4.x to work in 6.x is what we're here to talk about.

We probably want to show the toolbar when someone just asks for the locationbar.
And perhaps show an alternate toolbar without buttons (!) but no one has brought
that idea up before just now. Pretend I didn't. I originally closed this bug
"won't fix" because I didn't want hard C++ code which opened the toolbar in this
case, when it's a function of the particular XUL UI in use at the time.

Then it struck me that -- duh -- the same code that defines the relationship
between the location and toolbars would be the place to link their behaviour:
the XUL front-end. Close it "won't fix" if you like; that would be the second
time for this bug after all. But it is a compatibility and expectations issue.

Comment 24

[Rafael Ebron (:rebron)]

Todd,

We may need to fix this one for 0.9.9 or 1.0.  

Comment 25

[Todd Pringle]

Rafael, can you provide some justification about why you think this is
important?  I'm not convinced that this affects very many users very frequently.
 And certainly the severity is pretty low.

Comment 26

[Thomas Breitkreuz]

Hi,we need a differential control for all three bars for Browser based Intranet applications. Bye Thomas

Comment 27

[Peter Trudelle]

nsbeta1+ per Nav triage team, ->1.0

Comment 28

[Blake Ross]

Attachment: patch

the small throbber (used for fullscreen) is a bit too small...just an added
touch, we don't have to use it.

Comment 29

[Blake Ross]

-> me

Comment 30

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 71230 [details] [diff] [review]
patch

sr=[e-mail]

Comment 31

[Joe Hewitt (gone)]

Comment on attachment 71230 [details] [diff] [review]
patch

r=hewitt, conditional on blake moving all this to navigator.css, as we just
discussed on aim

Comment 32

[Asa Dotzler [:asa]]

a=asa (on behalf of drivers) for checkin to 0.9.9

Comment 33

[Blake Ross]

Fixed.

Comment 34

[[e-mail]]

When Joe Hewitt wrote "move all this to navigator.css"
a) did he mean navigator/content/navigator.css or navigator/skin/navigator.css?
   There are skin image URLS in there which are bad in content :-(
b) doesn't this break the Mac OSX chome toggling widget?
   I'm afraid I can't recall the bug number offhand, as I don't have OSX or a Mac!

Comment 35

[Prashant Desale]

The original problem does not seem to be fixed. The reporters testcase fails & 
also if we try Jon's testcase, it shows new window without location-bar when 
only "toolbar=yes". NS4.x & IE also behave in same way. 

But questions is what are we deciding to do. Leave the way it is or fix this 
problem. We need to mark this bug "WONTFIX" if we decide to leave it as it is.
Or we can try fixing original problem which was reported, hence I'm re-opening 
the bug.

Comment 36

[John Morrison]

Okay. The original proposition "no url bar when using window.open and toolbar=yes"
was in fact the correct behavior. But I noted that there were problems when 
only saying "location=yes" [my bad; morphed bug]. And after some back and forth,
a fix was checked in so that "location=yes" and "toolbar=yes" could be used 
independently, like they can be used in Nav4.x and IE. So this bug is fixed, no?

Comment 37

[Prashant Desale]

ok...in that case I'll mark it verified then. Thanks for clarification John.