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)
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: djoham, Assigned: bugzilla)
References
Details
Attachments
(5 files)
229 bytes,
text/html
|
Details | |
78.94 KB,
image/gif
|
Details | |
563 bytes,
text/html
|
Details | |
966 bytes,
text/html
|
Details | |
1.32 KB,
patch
|
hewitt
:
review+
bugs
:
superreview+
|
Details | Diff | Splinter Review |
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.
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•24 years ago
|
||
Confirming. No idea whose bug it should be, but it is real.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•24 years ago
|
||
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
Comment 7•24 years ago
|
||
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
Comment 8•24 years ago
|
||
Updated•24 years ago
|
Keywords: relnoteRTM
Summary: no url bar when using window.open and toolbar=yes → no urlbar when using window.open and only 'location=yes'
Comment 9•24 years ago
|
||
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'")
Reporter | ||
Comment 10•24 years ago
|
||
John,
Well, I learn something new every day. I wasn't aware of the location attribute.
Thanks for the explanation.
David
Comment 11•24 years ago
|
||
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
Comment 12•24 years ago
|
||
*** Bug 55324 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
*** Bug 66670 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
Marking Verified WONTFIX according to danm's comments.
Status: RESOLVED → VERIFIED
Comment 15•24 years ago
|
||
*** Bug 79380 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
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•23 years ago
|
||
*** Bug 99046 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
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 → ---
Comment 19•23 years ago
|
||
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
Comment 21•23 years ago
|
||
*** Bug 96147 has been marked as a duplicate of this bug. ***
Comment 22•23 years ago
|
||
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
Comment 23•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla1.1
Comment 24•23 years ago
|
||
Todd,
We may need to fix this one for 0.9.9 or 1.0.
Comment 25•23 years ago
|
||
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•23 years ago
|
||
Hi,we need a differential control for all three bars for Browser based Intranet applications. Bye Thomas
Comment 27•23 years ago
|
||
nsbeta1+ per Nav triage team, ->1.0
Assignee | ||
Comment 28•23 years ago
|
||
the small throbber (used for fullscreen) is a bit too small...just an added
touch, we don't have to use it.
Comment 30•23 years ago
|
||
Attachment #71230 -
Flags: superreview+
Comment 31•23 years ago
|
||
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+
Assignee | ||
Comment 33•23 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 34•23 years ago
|
||
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•23 years ago
|
||
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 → ---
Comment 36•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
Comment 37•23 years ago
|
||
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.
Description
•