Re: The global object in browsers
On Feb 17, 2009, at 6:31 PM, Mark Miller wrote: On Tue, Feb 17, 2009 at 5:24 PM, Ian Hickson i...@hixie.ch wrote: Opera, Apple, and Mozilla. The HTML5 spec originally specced what IE does, namely throw an exception when running code whose global object doesn't match the current Window object, but Opera, Apple, and Mozilla rejected this on the grounds that it could not be implemented in a high- performance manner. They requested that the spec be changed to match what Mozilla and Safari do. What Opera does is known to be incompatible with deployed content (they expose Window objects that aren't === to each other). The browsers all do slightly different things. The HTML5 spec right now is a mix of what Gecko and Webkit do. Now that I think I understand current and how weak the legacy constraints are, why not simply spec that your WindowProxy is the object to treated as the ECMAScript global object? The consequence would be that both f() and g() in your original example would return 2. That would either allow access to new variable bindings to functions in old documents from different origins (violating security requirements, my constraint 2, from another email) or would require a security check for every global variable lookup (violating my performance constraint 3). Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 17, 2009, at 11:18 PM, Mark Miller wrote: You misunderstood me a bit, but no matter. Now that I better understand the constraints -- thanks! -- what I was trying to say is irrelevant. What I mess. I am at a loss to find anything sensible to recommend. I think that's how most of us who have studied the issue feel. The split window solution is in some ways inelegant, but there is no obvious other option that satisfies the performance, compatibility and security requirements. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Behavior of Decode with overlong utf-8
Unless I am misreading the specification (quite likely), the Decode function does not have any logic to protect against decoding overlong, but otherwise valid, UTF-8 sequences. Arguably this fails in step 29 since RFC 3629[1] states: It is important to note that the rows of the table are mutually exclusive, i.e., there is only one valid way to encode a given character. [...] Implementations of the decoding algorithm above MUST protect against decoding invalid sequences but it is not clear how to handle a faliure here. Existing implementations seem to disagree on this point, my limited testing showed: Spidermonkey: inserts a uFFFD replacement character Futhark: leaves the original percent-encoded characters Squirrelfish: Throws URIError V8: Decodes the overlong sequence IE/JScript: Decodes the overlong sequence Since the usual behavior for invalid percent encoded sequences is to throw URIError, I suggest making that happen in this case too. [1] http://www.rfc-editor.org/rfc/rfc3629.txt ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 17, 2009, at 11:18 PM, Mark Miller wrote: You misunderstood me a bit, but no matter. Sorry, I couldn't see how to interpret your proposal otherwise. Let me know what I missed if you like. Maciej's right, the object identities practically dictate split windows. I suppose the original DOM level 0 could have made the split explicit, but it was not implemented this way at all back in the day. Different browser implementors solved the security and performance problems in similar ways, to preserve the view of the persistent window container as the one true window object, really a proxy with multiple global objects hidden within it. The ability to use lexical scope (however the syntax turns out) and make the global variables truly lexical bindings in a top-level environment, not properties of some grotty object, is something I look forward to in Harmony: http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: assignment to eval in strict code
-Original Message- From: Mark S. Miller [mailto:erig...@google.com] Sent: Thursday, February 12, 2009 4:58 PM Good. So does anyone object to ES3.1-strict imposing the same restrictions on the magic name arguments as we will on eval? In strict mode, arguments is already defined using an ImmutableBinding so assigning to it will fail in a manner similar to assignment to eval. We probably should list both of these assignment situations in section 16 as errors that can be reported at parse time. As currently specified strict code can declare a formal parameter, var, or function named arguments but doing so blocks creation of an arguments object and its binding. Allen ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: The global object in browsers
On Tue, 17 Feb 2009, Allen Wirfs-Brock wrote: Perhaps this would be a good initial W3C HTML WG/ECMA TC-39 joint work item if we can expeditiously get past the bureaucratic hurdles. The fact that there isn't an existing consensus behavior among the major browsers would seem to present an opportunity to step back a bit and take a new look at the problem. This would be fine by me, though it should be noted that the people who will ultimately decide what the answer is here are those who will be implementing it, and there is nobody who falls into that camp who is on the public-h...@w3.org list and is not on the es-discuss list as far as I am aware. So it's not clear that there would be any benefit to the getting past the bureaucratic hurdles. I'm happy to spec into HTML5 whatever the majority of implementations eventually do (i.e. HTML5 will just track reality, whatever that is), I would hope the same applies to the ES specs. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 18, 2009, at 3:24 PM, Ian Hickson wrote: I'm happy to spec into HTML5 whatever the majority of implementations eventually do (i.e. HTML5 will just track reality, whatever that is), I would hope the same applies to the ES specs. :-) We do try to pave the cowpaths (without giving the biggest herds undue influence, or falling into other such traps -- I get lost driving around Boston, I hear it's cuz they paved the cowpaths back a century or two). You may remember us from such reality-inspired movies as Attack of the /[/]/ Killer RegExps and Don't throw for(i in null) from the Train. :-/ /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
