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
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)
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
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
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
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
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,
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
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,
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
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
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),
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
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
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
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,
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
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
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
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
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
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`
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
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
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
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
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
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
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
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
30 matches
Mail list logo
