Closed
Bug 53343
Opened 24 years ago
Closed 22 years ago
window.open removes all features when provided with empty features argument
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: jrspm, Assigned: danm.moz)
Details
(Keywords: dom0)
According to the O'Reilly "javascript: the definitive guide (3rd edition)" Page
732:
"Window Features:
If [the window features argument] is empty or not specified, all features are
present in the window"
However, this is not the case in mozilla.
If you open a window like this: window.open("","","") it will actually REMOVE
all features. The only way this will work is if you don't provide the features
argument at all, which, based on the quote above, is not the correct behavior.
Steps to reproduce:
1. call a function that does a window.open and provides an empty string
features argument ( ie... window.open("boo.html", "myWinName", "") )
2. click a link that calls the function.
Expected results:
A fully featured window
Actual results:
All features removed
This works in IE5.01 sp1. Netscape 4.xx behaves exactly like Mozilla currently
is, however, again, based upon the quote from O'Reilly, this is not the correct
behavior.
Jake
Reporter | ||
Comment 2•24 years ago
|
||
Please see the following bug which relates to these problems with window.open
on Mozilla:
http://bugzilla.mozilla.org/show_bug.cgi?id=53683
Jake
Oh, I remember why we did this. As hoju mentions, Navigator 4 works the same
way. We had web content developers who were using the a features flag of ""
explicitly to turn off all features. Making Mozilla work differently would break
them.
But in the post IE/Navigator apocalyptic world, maybe we should think about
adopting IE's way of doing things. Opening up for comment...
Face it: O'Reilly is unclear or wrong, Netscape is correct.
If you want to programmatically remove/add features by means of constructing
the feature string from an array of features then you end up with a 0 length
string with 0 features, REALLY MEANING 0 features, not all features.
The special case of "all features" is ALREADY reserved by the missing argument
case (default). The fact that Microsoft screwed this up shouldn't affect this
clean logic.
Changing this would mean that on JavaScript level, one would have to code a
workaround:
if (numberOfFeaturesRequested>0){
functionWithArgumentAsusual()
}else{
specialFunctionWithoutArguments()
}
Bad programming. Reserved for MSCE engineers to keep them gainfully employed.
Disgusting.
Reporter | ||
Comment 6•24 years ago
|
||
bht,
Look at danm's response. It looks like he is one of the people that actually
implemented this and he said it was done in response to developer wishes. There
have been a few other things implemented based on developer wishes such as the
BLINK tag (to name one developer requested abomination).
I can respect that you have a particular opinion on this, but I am basing mine
on the Javascript definitive reference and seem to have danm's support in
backing the fact that the original intent was was exactly what O'Reilly described.
I can understand you not wanting to change after you've now depended on this
(faulty?) logic, but you tell me what is easier:
1. have a Dynamic string that can contain arguments or no argument at all (empty
string) and have a single:
window.open('mypage.html', 'mywinname', mydynamicvariable)
OR
2. have forked code that goes:
if (mydynamicvariable.length > 0)
window.open('mypage.html', 'mywinname', mydynamicvariable)
else
window.open('mypage.html', 'mywinname')
This is basically turning your own argument against you. It really depends on
your point of view. You use nothing but the fact that Netscape implemented this
in the past (for the arbitrary reason danm discussed) and you coded to their
(non-standard) way of doing things and don't feel like changing as your argument
against my (supported) proposal.
The fact is, if O'Reilly is correct and if danm supports O'Reilly's take on
window.open(), then it is your way of doing things that causes unnecessary code
forks.
And even if the above wasn't the case, the fact that the majority of the browser
market uses IE which does work this way (and so does Opera, BTW), and given the
fact that Netscape 3 and 4 have lost most of the browser market share, I really
don't think your argument holds up.
If you want to argue against this, find it in some javascript specification.
O'Reilly must have gotten its information from somewhere in order to state that
an empty string for a window features argument means "all features". If you
find that and tell me where to view this spec, I may reconsider. I'm all ears
(eyes, actually).
Jake
Comment 7•24 years ago
|
||
Let me clear up one seeming misconception on this first off. There is no
recognized standard which covers the window.open method. The specific
functionality of the method is based only on previous implementations and
analysis of current market needs.
That said, since Netscape originally developed the window.open method I tend to
lean towards our documentation on the matter. The url is
http://developer.netscape.com/docs/manuals/js/client/jsref/window.htm#1202731
but the specific applicable text is
"If windowName does not specify an existing window and you do not supply the
windowFeatures parameter, all of the features which have a yes/no
choice are yes by default. However, if you do supply the windowFeatures
parameter, then the titlebar and hotkeys are still yes by default, but
the other features which have a yes/no choice are no by default."
I don't believe the logic is faulty, it was designed this way. The O'Reilly book
is either wrong or biased towards IE. In any case, seeing as this is a
non-standardized area the only argument I see that really holds weight is that
of prevailing marketshare. However, we also have an obligation to previous
Netscape developers. In cases where we have no pre-established behavior I'm
happy to go with the flow but when doing so would break previous Netscape
developers I'm not inclined to make changes. That's my stance on this anyway.
Reporter | ||
Comment 8•24 years ago
|
||
Ok, that's at least something to base bht's argument on.
I still dislike the behavior.
If you wanted only a couple specific features, why would you not specifiy those
features to be true (automatically turning off all other non-specified features).
So, in the case the documentation talks about, all a person would have to do to
get exactly equivalent functionality out of all browsers on the market is:
window.open('mypage.html', 'mywinname', 'titlebar=yes,hotkeys=yes')
There you go, everyone is happy.
If this change were made, there would be consistent behavior for all browsers
from this day forward. I have never actually seen a developer use an empty
features argument to turn off all features. If I want specific features, I
specifically state that.
It does not matter if Netscape came up with window.open. The overwhelming
majority of web developers (and browser makers) assume O'Reilly's way. Also, is
Opera "biased toward IE"? I'd bet that Opera developers/users dislike IE more
than Netscape devotees, yet they use that behavior.
An empty string should not affect anything. It should be the same thing as not
providing the argument. If you make the change to Mozilla now, you avoid
requiring developers to fork code as I explained earlier.
Also, given that stuff needs to work on both Netscape and IE for a successful
web site, I think Netscape's useage of the empty windowfeatures argument is
utilized very rarely on the web and, as I've shown, it is as easy as adding
'titlebar=yes,hotkeys=yes' for the few that actually counted on that behavior.
You can end the inconsistencies for window.open from now on by making this
change. Please do.
Jake
This is fun.
Jake, your logic and O'Reilly's is wrong and those people who have a
brain don't want it to be brainwashed by incorrect logic.
There is no need for a spec really because this is all commonsense.
In this case I think it is probably just a glitch caused by a
technical writer in the book.
There are 2 cases:
1) Parameter-specified feature parameters.
Parameters can specify (specifically) any features.
This case includes the possibility of "no features" corresponding
to a 0 length string as much as an array of strings includes the
possibility of having 0 length -> which means a feature-less window.
The important point here is that
"no features" is always correctly defined by the 0 length string ""
and NOT by:
turning off explicitely all options that are not required
which is the consequence of O'Reilly's logic.
This is the stuff that causes maintenance effort as soon as additional
options are introduced in a browser after these options are coded
in a script.
O'Reilly's logic does not allow to open a feature-less window
without either specifying at least one option or turning all
known options off specifically.
2) Default window features which depend on browser features implemented
in the browser and current user defaults.
This is a special case and needs either an unused value such as null
in the feature string or an additional parameter or as in Netscape's
implementation, a missing parameter.
A 0 length string is already part of case 1 and cannot be used to define
special case 2).
So this is the logic period and you have to decide whether you want
to use the clean easy way as in Netscape or the dirty hard way as you
suggest.
I doubt that any Netscape engineer will follow your suggestion.
(as much as I am sure that any shop assistent will laugh at you if
you tell them all things you don't want to buy).
I am sure that you will add a comment to this but I guarantee I am out
of here forever because I have better things to do.
Reporter | ||
Comment 10•24 years ago
|
||
Yep, bht, I'm sure I will add a comment (and nice attitude, BTW).
How did you ever come up with this? You attempted to slam an argument that I
specifically did not make.
you said:
"turning off explicitely all options that are not required
which is the consequence of O'Reilly's logic."
When did I or O'Reilly ever say this?
I only ever argued in the affirmative. That is, you get exactly what you ask
for. It takes exactly 24 characters in the affirmative to tell Netscape to
create a window with exactly the features that Netscape's version of a
"featureless window" contains; 'titlebar=yes,hotkeys=yes'.
In that example, did you notice any point in which I asked for stuff I didn't want?
You said:
" O'Reilly's logic does not allow to open a feature-less window
without either specifying at least one option or turning all
known options off specifically."
Why in the world would you ever choose to turn all known options off
specifically? They are off by default. That hasn't changed. Notice the first
part of that sentence; "specifying at least one option". I've already shown you
that. The reason you have to specify something is to say specifically what you
*want*, not what you don't want. What don't you get???
There is no "maintainance effort" with IE's way of doing things. Unless the
windowfeature names change like "locationbar" becomes "locbar" or the definition
of a "featureless window" changes from its current definition of "titlebar" and
"hotkeys", there is nothing to worry about. New features would be off by
default which is *exactly* the same thing that would happen in with Netscape's
behavior.
And I've already made the argument for Market share and browser compatibility.
So, really, bht, what is your problem with this?
I know you aren't going to change your mind and I know Netscape will likely not
change their's either, but I convinced Mozilla developers to modify Mozilla's
cookie behavior to work more like IE's after lengthy discussion.
See bug 28956 for details if you care. It is definitely worth fighting for
something that you deem worthy.
bht, I now leave you to your holier-than-thou world in peace.
Jake
Reporter | ||
Comment 11•23 years ago
|
||
Dan,
Is this bug still up for fixing? There are two options:
1. Fix it to work like IE
2. Mark WontFix and leave it as NS4 works
I'd still like the IE behavior (much to bht's chagrin), but at this point, I
really don't care what happens. I'd rather have at least some resolution for
this bug.
Jake
Comment 12•22 years ago
|
||
If this bug is still active?
If I follow the steps to reproduce, I end up with the expected results. (The
only minor difference I see with MSIE 6 for Windows is that MSIE 6 for Windows
will NOT maximized the sub-window, therefore visually helping the user noticing
that a new window has popup.)
window.open("boo.html", "myWinName", "")
will create a maximized sub-window with ALL of its window features in Mozilla
1.3beta 2003012008, in Phoenix 0.5 build 20030112 and in NS 7.01; all in XP Pro SP1.
So, as far as I'm concerned, this bug should be resolved as WORKSFORME.
Assignee | ||
Comment 13•22 years ago
|
||
Huh. Looks like somebody (I wonder if it was me?) did an end-run and made
open(<url>, <name>, "") work as this bug requested. And no one noticed until
now. Snort. Good arguments both ways, personally I tend toward IE compatibility,
here we are. WFM.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 14•22 years ago
|
||
Woohooo!
Jake
You need to log in
before you can comment on or make changes to this bug.
Description
•