Closed Bug 53496 Opened 24 years ago Closed 23 years ago

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

Categories

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

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: djoham, Assigned: bugzilla)

References

Details

Attachments

(5 files)

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.
Attached file test case
Attached image screenshot
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.
Confirming. No idea whose bug it should be, but it is real.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yup, it's real, I see this too (on linux), I don't know who this would belong to either, maybe hyatt knows?
Assignee: jst → hyatt
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))
Assignee: hyatt → danm
Severity: major → normal
Keywords: relnoteRTM
Summary: no url bar when using window.open and toolbar=yes → no urlbar when using window.open and only 'location=yes'
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'")
John, Well, I learn something new every day. I wasn't aware of the location attribute. Thanks for the explanation. David
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.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
*** Bug 55324 has been marked as a duplicate of this bug. ***
*** Bug 66670 has been marked as a duplicate of this bug. ***
Marking Verified WONTFIX according to danm's comments.
Status: RESOLVED → VERIFIED
*** Bug 79380 has been marked as a duplicate of this bug. ***
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.
*** Bug 99046 has been marked as a duplicate of this bug. ***
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.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
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.
Assignee: danm → trudelle
Status: REOPENED → NEW
OS: Linux → All
->ben, p3/096
Assignee: trudelle → ben
Target Milestone: --- → mozilla0.9.6
*** Bug 96147 has been marked as a duplicate of this bug. ***
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.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla1.0
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.
Target Milestone: mozilla1.0 → mozilla1.1
Todd, We may need to fix this one for 0.9.9 or 1.0.
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.
Hi,we need a differential control for all three bars for Browser based Intranet applications. Bye Thomas
Keywords: nsbeta1
nsbeta1+ per Nav triage team, ->1.0
Keywords: nsbeta1nsbeta1+
Target Milestone: mozilla1.1 → mozilla1.0
Attached patch patchSplinter Review
the small throbber (used for fullscreen) is a bit too small...just an added touch, we don't have to use it.
-> me
Assignee: ben → blaker
Status: ASSIGNED → NEW
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
Attachment #71230 - Flags: review+
a=asa (on behalf of drivers) for checkin to 0.9.9
Keywords: mozilla0.9.9+
Fixed.
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
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!
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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?
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
ok...in that case I'll mark it verified then. Thanks for clarification John.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: