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)

x86
Windows 2000
defect

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
Dan, here's one for you! :-)
Assignee: jst → danm
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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: 4xp, correctness, nsbeta3
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...
Keywords: 4xp, nsbeta3
->future
Target Milestone: --- → Future
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.
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
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.
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.
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
Keywords: dom0
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
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.
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
Woohooo! Jake
You need to log in before you can comment on or make changes to this bug.