i see no reason to honor this key. the current code is following win IE's implementation, but neither firefox nor opera support this. see, e.g.
Created attachment 17502 [details]
Comment on attachment 17502 [details]
+ // Ignore resizable key
+ // else if (keyString == "resizable")
+ // windowFeatures.resizable = value;
We don't like to leave commented-out code in our source tree. Having a comment about ignoring resizable is good (perhaps at the start of this if/else chain), but the code should just be removed.
+ // Default to true
+ windowFeatures.resizable = true;
This comment should be omitted, as it add any information to the code below it.
Should we just remove windowFeatures.resizable entirely?
r- so the above issues can be fixed.
Created attachment 17512 [details]
Comment on attachment 17512 [details]
- The IE rule is: all features except for channelmode and fullscreen default to YES, but
- if the user specifies a feature string, all features default to NO. (There is no public
- standard that applies to this method.)
+ The IE rule is: all features except for channelmode and fullscreen default to YES, but if the user specifies a feature string, all features default to NO. (There is no public standard that applies to this method.)
I think the newlines here should be restored.
r=me, but whoever lands this should fix the above issue.
Landed in r28300.
The change to window-open-features-parsing.html was incorrect. If you want to change the expected result, fine. But you can't change the parsed string -- the whole point of the test is to see how the browser parses the string as a whole.
Fixed in revision 28310.
Now that I think about it more, we probably shouldn't have made this change in WebKit at all. WebKit has a responsibility to report the data fed to window.open to its client. It's up to the client to decide upon a behavior. If we want windows in Safari always to be resizable, then Safari should implement that policy, not WebKit.