Re: [whatwg] Proposal for separating script downloads and execution
On Thu, 2011-02-17 at 15:24 -0500, Boris Zbarsky wrote:
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for every script element?
For the most part this seems to be the case but there are two exceptions:
a) Before a URL loads, if it's assigned to another script, only one
request is made.
b) IE seems to always cache when the Back button is used.
Right: http://digital-fulcrum.com/webperf/readystate-caching/load-then-exec/
Wrong:
http://digital-fulcrum.com/webperf/readystate-caching/batch-load-then-exec/
2) If you create a bunch of script elements and set src on them all
and the script returned is different on every GET, and then you run
them, do you see all the different scripts running?
Yes, except for the two cases mentioned above.
3) If you do that experiment with 1,000 scripts all of which return
the same 50KB of data and none of which you insert, do you see
memory usage go up by 50MB? Does this depend on whether the
requests can be satisfied from cache or not?
It seems memory usage climbs with the number of
loaded-but-not-executed scripts, regardless of the caching state of
the URL, and declines as they are attached.
IE 9 may mitigate this to some degree by enforcing its standard
garbage collection rules. If only circular references to the script
element exist, IE will abort the network request and never fire the
readystatechange event.
(function(){
var s= create('script');
s.src=
s.onreadystatechange= function(){addToDom(this);};
})();
http://digital-fulcrum.com/webperf/ieabort/fail/
Will
Re: [whatwg] Proposal for separating script downloads and execution
On 2/22/11 1:25 PM, Will Alexander wrote:
On Thu, 2011-02-17 at 15:24 -0500, Boris Zbarsky wrote:
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for everyscript element?
For the most part this seems to be the case but there are two exceptions:
a) Before a URL loads, if it's assigned to another script, only one
request is made.
OK, that would be a violation of the HTTP caching semantics.
2) If you create a bunch ofscript elements and set src on them all
and the script returned is different on every GET, and then you run
them, do you see all the different scripts running?
Yes, except for the two cases mentioned above.
OK.
IE 9 may mitigate this to some degree by enforcing its standard
garbage collection rules. If only circular references to the script
element exist, IE will abort the network request and never fire the
readystatechange event.
(function(){
var s= create('script');
s.src=
s.onreadystatechange= function(){addToDom(this);};
})();
Uh... In that situation I would expect the event handler to keep the
script alive until the load finishes. Anything else is just a bug that
exposes GC timing to the web page.
-Boris
Re: [whatwg] Proposal for separating script downloads and execution
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for everyscript element?
For the most part this seems to be the case but there are two exceptions:
a) Before a URL loads, if it's assigned to another script, only one
request is made.
OK, that would be a violation of the HTTP caching semantics.
Can you explain how, in more detail? In practice I haven't seen IE's
behavior be a problem, but perhaps I'm not seeing the full context of the
issue you're concerned with.
IE 9 may mitigate this to some degree by enforcing its standard
garbage collection rules. If only circular references to the script
element exist, IE will abort the network request and never fire the
readystatechange event.
(function(){
var s= create('script');
s.src=
s.onreadystatechange= function(){addToDom(this);};
})();
Uh... In that situation I would expect the event handler to keep the
script alive until the load finishes. Anything else is just a bug that
exposes GC timing to the web page.
I've said the same thing to Will before. I agree that a script having a
circular reference to itself via the closure that's created when its handler
is created and assigned... *should* have kept the item alive and not GC'd. I
don't understand why IE GC's in this way.
In any case, for all intents and purposes, for someone to be using the
preloading as we're suggesting (with either proposal), you'd have to keep
around a reference to the script element anyway, so that you could later
programmatically execute it. So, I think this GC quirk of IE would in
practice mostly be avoided.
--Kyle
Re: [whatwg] Proposal for separating script downloads and execution
On 2/22/11 1:50 PM, Kyle Simpson wrote: 1) If your script is no-cache, or max-age:0, does IE make a new request for it for everyscript element? For the most part this seems to be the case but there are two exceptions: a) Before a URL loads, if it's assigned to another script, only one request is made. OK, that would be a violation of the HTTP caching semantics. Can you explain how, in more detail? In practice I haven't seen IE's behavior be a problem, but perhaps I'm not seeing the full context of the issue you're concerned with. If I have a response set to no-cache and you make two requests for it but only one of those actually hits the server, then you're clearly caching it in violation of the no-cache header. Is that really that unclear? Uh... In that situation I would expect the event handler to keep the script alive until the load finishes. Anything else is just a bug that exposes GC timing to the web page. I've said the same thing to Will before. I agree that a script having a circular reference to itself via the closure that's created when its handler is created and assigned... *should* have kept the item alive and not GC'd. I don't understand why IE GC's in this way. Because it's the easy way to do it; we had to jump through some hoops in Gecko to make sure an async XHR stays alive until it fires its last readystate change event when no one is holding a ref to the XHR object. In any case, for all intents and purposes, for someone to be using the preloading as we're suggesting (with either proposal), you'd have to keep around a reference to the script element anyway, so that you could later programmatically execute it. Well... no. You could grab the ref in the onreadystatechange handler. -Boris
Re: [whatwg] Websockets Client API
I went through exactly the same exercise some days ago. It turns out that the perfectly clear specification is the specification of the Javascript runtime environment, not in the particular API specification. obTangentEven in that case, I would prefer to see a separate open call. It's just cleaner to have the act of object creation separated from the act of external communication./obTangent. On 02/21/11 03:51, Robert O'Callahan wrote: On Mon, Feb 21, 2011 at 2:34 PM, Bruce Athertonbr...@callenish.com wrote: Perhaps you are reading a different spec than I am. The only language I see about queuing tasks involves changing the ready state on the Websocket object. There is nothing in there about waiting until a block of other Javascript code has run before making any other event callbacks. http://dev.w3.org/html5/websockets/#feedback-from-the-protocol For every event in that section, the user-agent must queue a task to fire the event. None of the other sections describe any events. Let me see if I follow the perfectly clear line of reasoning you are using. Your assumption is that a Websocket connection will only be loaded in an event handler like window.onload. In HTML5-compliant user-agents, all Javascript runs in some task of the HTML5 event loop. That task must run to completion before other tasks queued by the user-agent will run. No other events will be delivered until the current event handler finishes. And the event handler that creates the Websocket object will necessarily also be where the event handlers are set on the Websocket object. By making all of these assumptions, it becomes obvious that within a browser this API is safe for callbacks. Do I have that right? Yes. You observe correctly that the Web author has to be careful to ensure that the event handlers are set on the Websocket object during the same task that created it. However, this is a fairly natural requirement that is common in the Web platform. I am reminded of a joke about mathematicians. One argues that it is obvious that claim A follows from B. The other disagrees. After arguing for an hour, the latter finally agrees that A obviously follows from B. Yeah :-). By perfectly clear I meant that the spec was unambiguous, rather than obvious to the casual reader :-). Rob
Re: [whatwg] Proposal for separating script downloads and execution
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for everyscript element?
For the most part this seems to be the case but there are two
exceptions:
a) Before a URL loads, if it's assigned to another script, only one
request is made.
OK, that would be a violation of the HTTP caching semantics.
Can you explain how, in more detail? In practice I haven't seen IE's
behavior be a problem, but perhaps I'm not seeing the full context of
the issue you're concerned with.
If I have a response set to no-cache and you make two requests for it but
only one of those actually hits the server, then you're clearly caching it
in violation of the no-cache header. Is that really that unclear?
Look above at what Will says... he says before a URL loads in (a). I
interpreted that to mean that if I make two requests in rapid fire
succession, and the browser hasn't yet gotten the response headers (from the
first request) to tell it not to cache, then it makes sense from an
optimization standpoint that IE would see the two simultaneous URL requests
as the same and assume to only load once instead of twice.
Again, maybe I'm missing something, but the way Will describes it sounds
perfectly reasonable to me. It might be slightly on the aggressive side, but
I don't see how that, as described, is violating the HTTP caching semantics.
I don't see that those semantics imply that a browser must wait to fully
receive response-headers from a first request before deciding what to do
with a second request of the same URL.
Because it's the easy way to do it; we had to jump through some hoops in
Gecko to make sure an async XHR stays alive until it fires its last
readystate change event when no one is holding a ref to the XHR object.
Right, but in that case, the XHR object has a circular reference to itself
via the closure of the handler function (assuming it was an assigned
anonymous or in-scope function that was assigned). I was just saying that in
the case of actual DOM elements, when a circular reference is created
between the DOM element and a JS counter-part, through the closure of a
handler assigned to the element, I assumed this was enough to avoid GC.
I recall in older IE days avoiding stuff like:
var script = document.createElement(script);
script.theobj = script;
Because this created a circular reference, and thus a memory-leak, if you
didn't forcibly unset before unload the `theobj` reference to break the
circular ref.
In any case, for all intents and purposes, for someone to be using the
preloading as we're suggesting (with either proposal), you'd have to
keep around a reference to the script element anyway, so that you could
later programmatically execute it.
Well... no. You could grab the ref in the onreadystatechange handler.
In the most rudimentary of cases, and only assuming the `onreadystatechange`
handler actually had a closure reference to the script element... it
wouldn't if say you just made reference to some outer/global scope function
that you just assigned to the `onreadystatechange` property, like:
function handle(rs) {
if (rs == loaded) { ... }
// but, no ref to script object in here
}
(function(){
var script = document.createElement(script);
script.onreadystatechange = handle;
script.src = ...;
// append to DOM
})();
Also, there's a whole set of more advanced preloader functionality at
stake for script loaders which wouldn't suffice *even if* the only reference
to a script element was via closure in the handler (and that was sufficient
to avoid GC). For instance, a script loader that needs to load a dozen
script files all in parallel, then execute some of them in particular order,
while others in just first-come-first-served order... he can't just
daisy-chain off the handlers, he needs to actually have a reference kept for
each script element, so that he can specifically execute each one in their
proper order.
My point was, in practice, most advanced usages of preloading are in fact
going to have to keep around the reference, thus the GC isn't going to be an
issue. Only in the simple basic subset of the main proposal use-case would
this GC bug arise. And it's easily worked around by keeping a ref in scope.
--Kyle
Re: [whatwg] Proposal for separating script downloads and execution
On 2/22/11 3:07 PM, Kyle Simpson wrote: Look above at what Will says... he says before a URL loads in (a). I interpreted that to mean that if I make two requests in rapid fire succession, and the browser hasn't yet gotten the response headers (from the first request) to tell it not to cache, then it makes sense from an optimization standpoint that IE would see the two simultaneous URL requests as the same and assume to only load once instead of twice. That's a violation of HTTP semantics, yes. A convenient way to write the code, but a violation of HTTP semantics. Again, maybe I'm missing something, but the way Will describes it sounds perfectly reasonable to me. It might be slightly on the aggressive side, but I don't see how that, as described, is violating the HTTP caching semantics. Trivially. If it's not in your cache at all, you're supposed to make a request to the server! If you're not doing that, then you're not implementing HTTP. I don't see that those semantics imply that a browser must wait to fully receive response-headers from a first request before deciding what to do with a second request of the same URL. Right. They just imply that you need to send the second request. Or wait for the first to come and then decide whether to send it. Or _something_ that looks like what HTTP is supposed to look like. What _this_ looks like is that there's a non-HTTP cache of in-progress loads that can serve to coalesce said in-progress loads. That gives behavior that's invalid per HTTP and inherently racy in a bad way. Because it's the easy way to do it; we had to jump through some hoops in Gecko to make sure an async XHR stays alive until it fires its last readystate change event when no one is holding a ref to the XHR object. Right, but in that case, the XHR object has a circular reference to itself via the closure of the handler function (assuming it was an assigned anonymous or in-scope function that was assigned). Sure. I was just saying that in the case of actual DOM elements, when a circular reference is created between the DOM element and a JS counter-part, through the closure of a handler assigned to the element, I assumed this was enough to avoid GC. Circular references can't be enough to avoid GC. The whole point of having a GC is to be able to collect entire subgraphs of the object graph that are not rooted. And you have to be able to collect cyclic subgraphs; otherwise you might as well use reference counting instead of a GC. I recall in older IE days avoiding stuff like: var script = document.createElement(script); script.theobj = script; Because this created a circular reference, and thus a memory-leak, if you didn't forcibly unset before unload the `theobj` reference to break the circular ref. Yes, that would be due to the fact that GC was used on the JS side and something else on the C++ side and the expando caused the script to be a GC root. Other browsers have had similar bugs too. Those are just bugs to fix. A GC should be able to collect the above. Well... no. You could grab the ref in the onreadystatechange handler. In the most rudimentary of cases, and only assuming the `onreadystatechange` handler actually had a closure reference to the script element... |this| is the script element in the onreadystatechange handler, I would think. So it _always_ has a reference to the script element. Just like the XHR onreadystatechange case. he can't just daisy-chain off the handlers, he needs to actually have a reference kept for each script element, so that he can specifically execute each one in their proper order. Yes, but it could just grab those references as the scripts load. In any way, this is a side-issue; my main question has been answered: IE both shows bad memory behavior _and_ fails to implement HTTP semantics for script preloads done in this way. -Boris -Boris
Re: [whatwg] Cryptographically strong random numbers
On 22/02/2011, at 22:36, Brendan Eich wrote: (...) However, Math.random is a source of bugs as Amit Klein has shown, and these can't all be fixed by using a better non-CS PRNG underneath Math.random and still decimating to an IEEE double in [0, 1]. The use-cases Klein explored need both a CS-PRNG and more bits, IIRC. Security experts should correct amateur-me if I'm mistaken. .replace( /1]/gm, '1)' ) ? -- Jorge.
Re: [whatwg] Cryptographically strong random numbers
On Feb 22, 2011, at 2:00 PM, Jorge wrote: On 22/02/2011, at 22:36, Brendan Eich wrote: (...) However, Math.random is a source of bugs as Amit Klein has shown, and these can't all be fixed by using a better non-CS PRNG underneath Math.random and still decimating to an IEEE double in [0, 1]. The use-cases Klein explored need both a CS-PRNG and more bits, IIRC. Security experts should correct amateur-me if I'm mistaken. .replace( /1]/gm, '1)' ) ? Right. Reading more of Amit Klein's papers, the rounding to IEEE double also seems problematic. Again, I'm not the crypto-droid you are looking for. /be
Re: [whatwg] Cryptographically strong random numbers
I can find Klein's complaints that the implementation of Math.random is insecure but not his complaints about the API. Do you have a link? It seems pretty simple to generate a random number from 1 to 2 by fixing the exponent and mixing in 52 bits of random mantissa. Subtract 1 to get an evenly distributed value from 0-1. Multiply and Math.floor or to get your 8, 16, or 32 bits of randomness. On Feb 22, 2011 11:04 PM, Brendan Eich bren...@mozilla.org wrote: On Feb 22, 2011, at 2:00 PM, Jorge wrote: On 22/02/2011, at 22:36, Brendan Eich wrote: (...) However, Math.random is a source of bugs as Amit Klein has shown, and these can't all be fixed by using a better non-CS PRNG underneath Math.random and still decimating to an IEEE double in [0, 1]. The use-cases Klein explored need both a CS-PRNG and more bits, IIRC. Security experts should correct amateur-me if I'm mistaken. .replace( /1]/gm, '1)' ) ? Right. Reading more of Amit Klein's papers, the rounding to IEEE double also seems problematic. Again, I'm not the crypto-droid you are looking for. /be
Re: [whatwg] Proposal for separating script downloads and execution
On Tue, Feb 22, 2011 at 4:13 PM, Boris Zbarsky bzbar...@mit.edu wrote: Uh... In that situation I would expect the event handler to keep the script alive until the load finishes. Anything else is just a bug that exposes GC timing to the web page. Yes, quite strange. It's fixed in IE9 (at least my test no longer fails) so clearly considered a bug. IE shows ... bad memory behavior To your original point, Boris, if there's no way to reclaim the memory for a pre-fetched script _until_ its executed, then even legitimate use-cases (e.g. pre-fetching auto-completion data) by responsible authors would be of concern. Would a means by which authors can mark a pre-fetched script as stale allay some of your concerns? Is there some way to accomplish this in Gecko now for a pre-fetched Image?
Re: [whatwg] Cryptographically strong random numbers
On Feb 22, 2011, at 2:49 PM, Erik Corry wrote: I can find Klein's complaints that the implementation of Math.random is insecure but not his complaints about the API. Do you have a link? In the paper linked from http://seclists.org/bugtraq/2010/Dec/13 section 3 (3. The non-uniformity bug), viz: Due to issues with rounding when converting the 54 bit quantity to a double precision number (as explained in http://www.trusteer.com/sites/default/files/Temporary_User_Tracking_in_Major_Browsers.pdf section 2.1, x2 may not accurately represent the state bits if the whole double precision number is ≥0.5. but that link dangles, and I haven't had time to read more. The general concern about the API arises because Adam's API returns a typed array result that could have lenght 1, i.e., not a random result that fits in at most 32 (or even 53) bits. /be
Re: [whatwg] Proposal for separating script downloads and execution
On 2/22/11 6:21 PM, Will Alexander wrote: Would a means by which authors can mark a pre-fetched script as stale allay some of your concerns? I wouldn't expect anyone to actually use such a means. Is there some way to accomplish this in Gecko now for a pre-fetched Image? If you hold a reference to the img node we'll keep the image data around in some form (possibly still-compressed, etc; details depend on the Gecko version, possibly on whether the tab is currently focused, possibly on how much time has passed, etc). But note that image loads very explicitly do NOT have HTTP semantics, last I checked. In Gecko they coalesce very aggressively in a cache that sits in front of the network layer, including coalescing across documents, etc. This cache applies to both in-progress loads and completely loads (it's actually a cache of image objects). -Boris.
Re: [whatwg] Proposal for separating script downloads and execution
But note that image loads very explicitly do NOT have HTTP semantics, last I checked. In Gecko they coalesce very aggressively in a cache that sits in front of the network layer, including coalescing across documents, etc. This cache applies to both in-progress loads and completely loads (it's actually a cache of image objects). This seems strange to me. Generated images (like in captchas, etc) have to be common enough that the same semantics for don't cache unless I say it's ok would apply somewhat equally to JS as images, right? What's the reasoning that says that JS is more likely to be dynamically created (and thus needs proper always-request semantics) where images do not have that need? --Kyle
Re: [whatwg] Cryptographically strong random numbers
Thanks for the link. Having read the section in question I am satisfied that the author has no problem with the API. On Feb 23, 2011 12:34 AM, Brendan Eich bren...@mozilla.org wrote: On Feb 22, 2011, at 2:49 PM, Erik Corry wrote: I can find Klein's complaints that the implementation of Math.random is insecure but not his complaints about the API. Do you have a link? In the paper linked from http://seclists.org/bugtraq/2010/Dec/13 section 3 (3. The non-uniformity bug), viz: Due to issues with rounding when converting the 54 bit quantity to a double precision number (as explained in http://www.trusteer.com/sites/default/files/Temporary_User_Tracking_in_Major_Browsers.pdfsection 2.1, x2 may not accurately represent the state bits if the whole double precision number is ≥0.5. but that link dangles, and I haven't had time to read more. The general concern about the API arises because Adam's API returns a typed array result that could have lenght 1, i.e., not a random result that fits in at most 32 (or even 53) bits. /be
Re: [whatwg] Proposal for separating script downloads and execution
On 2/22/11 6:39 PM, Kyle Simpson wrote: This seems strange to me. Generated images (like in captchas, etc) have to be common enough The captchas I just looked at use different URIs for different captcha images. I oversimplified a bit: the image cache in Gecko does do some http-like stuff, but it defaults to handing back the already existing image data and then kicks off a request to validate if needed. This can cause the wrong image to show temporarily, until replaced by the right one (which I consider a bug; I think the cache needs to be less aggressive). That approach is clearly not workable for scripts... ;) -Boris
Re: [whatwg] Cryptographically strong random numbers
On Tue, Feb 22, 2011 at 6:26 PM, Bill Frantz fra...@pwpconsult.com wrote: On 2/22/11 at 1:36 PM, bren...@mozilla.com (Brendan Eich) wrote: However, Math.random is a source of bugs as Amit Klein has shown, and these can't all be fixed by using a better non-CS PRNG underneath Math.random and still decimating to an IEEE double in [0, 1]. The use-cases Klein explored need both a CS-PRNG and more bits, IIRC. Security experts should correct amateur-me if I'm mistaken. I'll see if the security expert hat fits. :-) The random() function in many languages has a useful property which is incompatible with security. By setting its seed, you can get deterministic execution of a Monte Carlo algorithm. I don't agree that being able to query and set the state of a PRNG is incompatible with security. Most comprehensive, secure PRNG APIs support doing that, eg. LTC's XXX_import and XXX_export functions. In fact, you can even do that with /dev/urandom in Linux (only as root, since it's shared across users). Neither Math.random nor any of the APIs discussed so far are attempt to be comprehensive APIs, of course. Using Math.random's API for secure random numbers wouldn't make sense, though. Secure random number sources from OS's give bytes, and most (all?) real-world crypto algorithms want bytes (or groups of bytes), so this would just be converting from bytes to floating-point and back to bytes anyway. That's just introducing a lot of new ways to get things wrong. -- Glenn Maynard
Re: [whatwg] Proposal for separating script downloads and execution
This can cause the wrong image to show temporarily, until replaced by the right one (which I consider a bug; I think the cache needs to be less aggressive). That approach is clearly not workable for scripts... ;) No, clearly not. I think we're finally in agreement on something. :) I think we need to refocus the thread. Boris, you've brought up issues of essentially: 1. Will keeping scripts around in memory that never get used lead to run-away memory usage? 2. Does the caching behavior of IE do incorrect things (that Mozilla would want to avoid)? For #1, I think we've established this is probably true (for those rare corner cases). Perhaps a more sophisticated in-memory content-uniqueness cache could be constructed, but it may be more work than it's worth. To push the ball forward, in a rough (non-binding) estimate, do you think that Mozilla could be persuaded to agree to either of the two proposals, granted the potential corner case negative performance, *without* such a sophisticated in-memory cache to address some of those concerns? If not, would the feasibility of such a system make implementing this proposal unlikely? Or would it just be a pre-requisite that made the implementation of preloading somewhat more complicated than it appears on the surface? For #2 (and several other related questions we've been exploring)... granted, it clearly seems that IE's implementation is not perfect (but is at least getting better as of IE9). But as with the above assertion/question about #1... if the correct thing is just to always follow HTTP semantics, and assume you have to request every URL until you get caching headers saying otherwise... isn't that still feasible within the constraints of either of the two main proposals? Granted that it would be diverging from IE's bugs in this area, but would it be workable to do so? If not, can you clearly articulate why you think the proposals could not fit with existing precedent on HTTP caching semantics? Also, I want to go back to a question I asked earlier in this thread and I don't think I quite got a full answer to: With respect to the HTTP caching semantics (or other related performance concerns), *other than the potential waste of unused scripts*, what additional concerns does preloading imply that the quite standard current practice of dynamically adding script elements to the DOM wouldn't imply? I'm trying to figure out why preloading presents additional challenges/risks that the current dynamic loading mechanisms don't. --Kyle
Re: [whatwg] Proposal for separating script downloads and execution
On 2/22/11 7:19 PM, Kyle Simpson wrote: For #1, I think we've established this is probably true (for those rare corner cases). Perhaps a more sophisticated in-memory content-uniqueness cache could be constructed, but it may be more work than it's worth. To push the ball forward, in a rough (non-binding) estimate, do you think that Mozilla could be persuaded to agree to either of the two proposals, granted the potential corner case negative performance, *without* such a sophisticated in-memory cache to address some of those concerns? First of all, which two proposals are we talking about here? If not, would the feasibility of such a system make implementing this proposal unlikely? It would certainly make implementing it soon unlikely, if such a beastie is needed. For #2 (and several other related questions we've been exploring)... granted, it clearly seems that IE's implementation is not perfect (but is at least getting better as of IE9). But as with the above assertion/question about #1... if the correct thing is just to always follow HTTP semantics That's an excellent question. Is that the correct thing? For some things (e.g. stylesheets and images) browsers don't do this in many cases (and the HTML5 spec in fact requires such behavior). What should the script behavior be? isn't that still feasible within the constraints of either of the two main proposals? Sure. My point was that coalescing loads in ways that HTTP doesn't actually allow is one way to handle the memory growth issue without exploding cache complexity. Also, I want to go back to a question I asked earlier in this thread and I don't think I quite got a full answer to: With respect to the HTTP caching semantics (or other related performance concerns), *other than the potential waste of unused scripts*, what additional concerns does preloading imply that the quite standard current practice of dynamically adding script elements to the DOM wouldn't imply? I'm trying to figure out why preloading presents additional challenges/risks that the current dynamic loading mechanisms don't. Because if you're trying to implement some sort of sophisticated in-memory content-uniqueness cache is also expected to implement HTTP semantics, that makes implementing it a good bit more difficult. -Boris
Re: [whatwg] Proposal for separating script downloads and execution
On Tue, Feb 22, 2011 at 6:35 PM, Boris Zbarsky bzbar...@mit.edu wrote: Would a means by which authors can mark a pre-fetched script as stale allay some of your concerns? I wouldn't expect anyone to actually use such a means. Understandable. I ask because at one point you stated if DOM attachment triggers the pre-load (instead of src assignment), that would address the memory consumption. It would seem that would require devs clean up after themselves too. Given you don't sound thrilled with some of the concessions required for Images, it sounds like you're more concerned with the consequences of pre-loading in general, not the specifics of an interface. Is that accurate? Will
Re: [whatwg] Proposal for separating script downloads and
First of all, which two proposals are we talking about here? 1. Nicholas' proposal, which is currently to preload a script if its script element is marked with a `preload` attribute, before the setting of the `src` property. To execute the script, you add the script element to the DOM. To detect when the preload finishes, you listen to the `onpreload` event. 2. My proposal, which is (by and large) to standardize the functionality that IE already has, and that the spec already suggests, which is that preloading happens when setting the `src` property before adding the script to the DOM. To execute, add the script to the DOM. TO detect when the preload finishes, listen for the `onreadystatechange` event to signal that the `readyState` property is loaded. It would certainly make implementing it soon unlikely, if such a beastie is needed. I guess that's the crux of the question. Is such a mechanism needed to make either of those two proposals something palatable to a browser like Mozilla? For #2 (and several other related questions we've been exploring)... granted, it clearly seems that IE's implementation is not perfect (but is at least getting better as of IE9). But as with the above assertion/question about #1... if the correct thing is just to always follow HTTP semantics That's an excellent question. Is that the correct thing? For some things (e.g. stylesheets and images) browsers don't do this in many cases (and the HTML5 spec in fact requires such behavior). What should the script behavior be? Let me restate: I'm not purporting to know what the semantics should or should not be. I'm suggesting they should be, per browser, exactly the same as normal dynamic script loading, in each browser, already behaves. In other words, I've been operating under the assumption that neither proposal requires explicitly defining or changing the current HTTP caching semantics. I'm hoping that if this assumption is wrong, someone can help me understand why? I don't understand why the preloading specifically would imply different HTTP caching semantics than normal dynamic script loading? --Kyle
Re: [whatwg] Proposal for separating script downloads and execution
On Tue, Feb 22, 2011 at 8:14 PM, Kyle Simpson get...@gmail.com wrote: First of all, which two proposals are we talking about here? 1. Nicholas' proposal, which is currently to preload a script if its script element is marked with a `preload` attribute, before the setting of the `src` property. To execute the script, you add the script element to the DOM. To detect when the preload finishes, you listen to the `onpreload` event. 2. My proposal, which is (by and large) to standardize the functionality that IE already has, and that the spec already suggests, which is that preloading happens when setting the `src` property before adding the script to the DOM. To execute, add the script to the DOM. TO detect when the preload finishes, listen for the `onreadystatechange` event to signal that the `readyState` property is loaded. To briefly restate the third proposal, so it's not lost in the noise: 3. My (and Nicholas's previous) proposal: Script elements are fetched when inserted into the DOM[1]. An event is dispatched when the script has been fetched, eg. onfetch or onpreload[2]. A preload attribute is added; when true, the script will not be executed when the fetch completes; call script.execute() to run the script. Aside from what I think are a lot of advantages of this approach, it avoids the issues behind mimicing the src behavior of images. It seems that's a bad precedent to follow--it's a compatibility hack, not something that should be copied. [1] Not to imply prohibiting IE's behavior of prefetching when src is set. This is just to contrast from #1 and #2: it doesn't become a requirement. [2] The proposal suggested onpreload, but there's no actual need for the script fetched event to be tied to preloading. I think onfetch makes more sense. -- Glenn Maynard
Re: [whatwg] Proposal for separating script downloads and execution
On 2/22/11 8:05 PM, Will Alexander wrote: I ask because at one point you stated if DOM attachment triggers the pre-load (instead of src assignment), that would address the memory consumption. Well, more precisely it would make it less likely that someone would accidentally author broken content. Because all current browsers load a script anyway, once it's in the DOM. Given you don't sound thrilled with some of the concessions required for Images, it sounds like you're more concerned with the consequences of pre-loading in general, not the specifics of an interface. I'm mostly concerned with changes from existing UA behavior that can cause scripts that don't blow up memory usage in current UAs to blow up memory usage in UAs that implement the new functionality, because such changes are risky for UA implementors. If a change has this property, then that just needs to be taken into account when evaluating it. -Boris
Re: [whatwg] Proposal for separating script downloads and
On 2/22/11 8:14 PM, Kyle Simpson wrote: First of all, which two proposals are we talking about here? 1. Nicholas' proposal, which is currently to preload a script if its script element is marked with a `preload` attribute, before the setting of the `src` property. To execute the script, you add the script element to the DOM. To detect when the preload finishes, you listen to the `onpreload` event. 2. My proposal, which is (by and large) to standardize the functionality that IE already has, and that the spec already suggests, which is that preloading happens when setting the `src` property before adding the script to the DOM. To execute, add the script to the DOM. TO detect when the preload finishes, listen for the `onreadystatechange` event to signal that the `readyState` property is loaded. The api of #2 seems somewhat cleaner to me. #1 seems safer to implement. I'm not sure which one I prefer... It would certainly make implementing it soon unlikely, if such a beastie is needed. I guess that's the crux of the question. Is such a mechanism needed to make either of those two proposals something palatable to a browser like Mozilla? I don't think we'd need anything like this for proposal #1 above. For #2, I'm not sure yet. For some things (e.g. stylesheets and images) browsers don't do this in many cases (and the HTML5 spec in fact requires such behavior). What should the script behavior be? Let me restate: I'm not purporting to know what the semantics should or should not be. I'm suggesting they should be, per browser, exactly the same as normal dynamic script loading, in each browser, already behaves. In other words, I've been operating under the assumption that neither proposal requires explicitly defining or changing the current HTTP caching semantics. I'm hoping that if this assumption is wrong, someone can help me understand why? This assumption is not wrong, per se. I don't understand why the preloading specifically would imply different HTTP caching semantics than normal dynamic script loading? It doesn't have to. It's just that if preloading is easy to trigger by accident and authors don't notice when they accidentally preload lots of stuff then we may have a problem if we don't coalesce identical-object (whatever that means) loads. Normal script loading doesn't have the don't notice issue much, because a typical script running is noticeable. -Boris
Re: [whatwg] Proposal for separating script downloads and execution
On 2/22/11 8:54 PM, Glenn Maynard wrote: 3. My (and Nicholas's previous) proposal: Script elements are fetched when inserted into the DOM[1]. An event is dispatched when the script has been fetched, eg. onfetch or onpreload[2]. A preload attribute is added; when true, the script will not be executed when the fetch completes; call script.execute() to run the script. I strongly prefer this proposal to either of the other two, for what it's worth. Is the concern that this doesn't degrade as nicely in UAs that don't support preload or something? If not, what _are_ the arguments against this proposal? Links to existing discussion are fine if this ground was already covered. -Boris
Re: [whatwg] Proposal for separating script downloads and execution
On Tue, Feb 22, 2011 at 9:24 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/22/11 8:54 PM, Glenn Maynard wrote: 3. My (and Nicholas's previous) proposal: Script elements are fetched when inserted into the DOM[1]. An event is dispatched when the script has been fetched, eg. onfetch or onpreload[2]. A preload attribute is added; when true, the script will not be executed when the fetch completes; call script.execute() to run the script. I strongly prefer this proposal to either of the other two, for what it's worth. Is the concern that this doesn't degrade as nicely in UAs that don't support preload or something? If not, what _are_ the arguments against this proposal? Links to existing discussion are fine if this ground was already covered. The main arguments for the readyState approach over this have been: it's what IE does now, and the preloading when src is set has precedent with images. I sympathize with that, since they're aiming to improve the likelihood of being implemented--but the precedent it's drawing on seems like a bad one, which should be treated as a compatibility hack rather than a precedent for new APIs. From what you've been saying it sounds like it would have the opposite effect, making it so hard to implement that it wouldn't gain traction. I also think the other side benefits of this approach are significant, so long as they don't make it too hard to implement. That really needs implementor feedback--if you can give that, let me know if you want a more detailed recap. -- Glenn Maynard
Re: [whatwg] Proposal for separating script downloads and execution
On 2/22/11 9:55 PM, Glenn Maynard wrote: The main arguments for the readyState approach over this have been: it's what IE does now, and the preloading when src is set has precedent with images. I sympathize with that, since they're aiming to improve the likelihood of being implemented--but the precedent it's drawing on seems like a bad one, which should be treated as a compatibility hack rather than a precedent for new APIs. From what you've been saying it sounds like it would have the opposite effect, making it so hard to implement that it wouldn't gain traction. I think that proposal 3 would be easier (or at least safer) for Mozilla to implement. Clearly IE's current behavior would be easier for IE to implement. ;) I'd like to know what Opera and Webkit folks think, in terms of implementation difficulty. I also think the other side benefits of this approach are significant, so long as they don't make it too hard to implement. That really needs implementor feedback--if you can give that, let me know if you want a more detailed recap. I don't think I do. Proposal 3 sounded fine to me last I saw it. -Boris
Re: [whatwg] Proposal for separating script downloads and execution
On Tue, Feb 22, 2011 at 10:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: I also think the other side benefits of this approach are significant, so long as they don't make it too hard to implement. That really needs implementor feedback--if you can give that, let me know if you want a more detailed recap. I don't think I do. Proposal 3 sounded fine to me last I saw it. Including execute() being synchronous, raising SyntaxError exceptions for parse errors, and uncaught exceptions from the script being propagated up through execute() to its caller? -- Glenn Maynard
Re: [whatwg] Proposal for separating script downloads and execution
On 2/22/11 10:42 PM, Glenn Maynard wrote: Including execute() being synchronous, raising SyntaxError exceptions for parse errors, and uncaught exceptions from the script being propagated up through execute() to its caller? Hmm. That last one might take some work in Gecko, if it's even sanely possible, but the rest of it shouldn't be that bad. -Boris
Re: [whatwg] Cryptographically strong random numbers
On Feb 22, 2011, at 3:45 PM, Erik Corry wrote:
Thanks for the link. Having read the section in question I am satisfied that
the author has no problem with the API.
In theory, sure. Bits are bits.
The practical issue is usability, where less usable interfaces tend to breed
more bugs, as I argued was a hazard of the proposal to return a plain old Array
containing uint16 values as elements. Glenn Maynard's point about more to go
wrong with IEEE double seem to be validated by the IE9 preview release
Math.random bugs that Amit Klein found. From the crypto-hacker point of view,
anything that makes it harder to get random uint{8,16,32} values than necessary
seems that much less good.
If we have only number type for the result, then Math.random is the API
template to match. Given typed arrays / binary data, Adam's API looks more
usable, even counting the cost of differing from Math.random in its API
signature.
/be
On Feb 23, 2011 12:34 AM, Brendan Eich bren...@mozilla.org wrote:
On Feb 22, 2011, at 2:49 PM, Erik Corry wrote:
I can find Klein's complaints that the implementation of Math.random is
insecure but not his complaints about the API. Do you have a link?
In the paper linked from http://seclists.org/bugtraq/2010/Dec/13 section 3
(3. The non-uniformity bug), viz:
Due to issues with rounding when converting the 54 bit quantity to a
double precision number (as explained in
http://www.trusteer.com/sites/default/files/Temporary_User_Tracking_in_Major_Browsers.pdf
section 2.1, x2 may not accurately represent the state bits if the whole
double precision number is ≥0.5.
but that link dangles, and I haven't had time to read more.
The general concern about the API arises because Adam's API returns a typed
array result that could have lenght 1, i.e., not a random result that
fits in at most 32 (or even 53) bits.
/be
___
es-discuss mailing list
es-disc...@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
