On Feb 21, 2009, at 1:49 AM, David-Sarah Hopwood wrote:
Ian Hickson wrote:
Right now ES3 assumes that there is a single global object, which
is used
at the top of the scope chain and that is returned for "this" in the
global scope.
It is possible to show that this is now what some browsers do:
var x = 1;
function f() { return x; }
var global = this;
function g() { return global.x; }
// some other page's script takes references to f and g
// browser navigates to a new page
var x = 2;
Now, if the other page's script calls f() and g(), it will get
different
results [...]
Suppose that a browser allocates all JavaScript objects associated
with
some unit of content [*], in an arena. When the browser navigates
away from
that unit of content, the arena is deallocated; to preserve memory
safety,
all references into it from objects that are still live will throw an
exception.
This behaviour has clear advantages for robustness against denial of
service
from JavaScript code, both deliberate and inadvertent -- which is a
definite
weak spot of current browsers, and a very common cause of complaint
from
knowledgeable users. Is there any reason why it should be considered
nonconformant?
This behavior has two problems:
1) Likely incompatible with the Web. Though Web sites apparently don't
depend on ability to call older functions, they certainly do use
objects originally allocated in other global objects and quite likely
after the originating context has navigated. It's hard to quantify
this since no browser has ever tried.
2) Makes implementation of back/forward caching (as present in Safari
and Firefox) impractical; b/f cache fully restores a context that you
navigated away from, including the live JavaScript object graph.
3) Has the same performance problems as the model of checking at
function call boundaries, since at calls you'd have to check if your
function has turned into a magical exception object. You are on record
as not believing these, I will leave it to others to judge for
themselves whether your "I'm quite sure" argument outweighs the
experience of those who actually tried it and measured the results.
4) If the arena is truly deallocated rather than filled with magic
exception objects, many additional checks must be inserted each time a
value reference is used in almost any way, to check whether it is a
reference into a deallocated arena. This would likely be a significant
perf hit as well.
5) As far as I can tell, this violates the ECMA spec even more than
the current HTML5 solution; the ECMA spec does not include the concept
of reachable values turning into exception-throwing zombies.
6) It has poor properties for reliability and integrity of ECMAScript
programs. Your code may have a perfectly good string or object stored
away. But depending on where it originally came from, that reference
can suddenly go bad.
[*] Possibly a frame, or consecutive sequence of navigated frames with
the same origin. What is the minimum granularity for a "unit of
content"
for this would be compatible with the current web?
A unit of content of one page is almost certainly incompatible with
the Web. A series of frames with the same origin would likely also be
incompatible, since it is quite likely an initially empty frame may be
used as a helper before navigating elsewhere. Not only that, but it
would be bizarrely arbitrary if your object references from another
frame go dead or not depending on whether the frame navigates to same-
origin or non-same-origin content. Either way, problems 2-5 remain.
I don't think we need to try to redesign how browsers do navigation
here. I don't see any justification provided for preferring your
approach to what HTML5 specifies.
Regards,
Maciej
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
