On Mon, May 6, 2013 at 5:57 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, May 6, 2013 at 5:45 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren ann...@annevk.nl wrote:
Okay. So that fails for XMLHttpRequest :-(
What do you mean? Those are the
On Mon, May 6, 2013 at 10:52 PM, Eric U er...@google.com wrote:
I'm not really sure what you're saying, here. If you want an URL to
expire or otherwise be revoked, no, you can't use it multiple times
after that. If you want it to work multiple times, don't revoke it or
don't set
On Mon, May 6, 2013 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote:
The only thing that's different about XHR is that the first step in my
list lives in one function, and the other steps live in another
function. Doesn't seem to have any effect on the discussions here
other than that we'd
On May 7, 2013, at 10:45 AM, Anne van Kesteren wrote:
On Mon, May 6, 2013 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote:
The only thing that's different about XHR is that the first step in my
list lives in one function, and the other steps live in another
function. Doesn't seem to have
On Tue, May 7, 2013 at 12:17 PM, Arun Ranganathan a...@mozilla.com wrote:
\o/ :-)
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=21955
So actually, after I emailed that this morning I wondered how this
would work for img srcset or image() in CSS where fetch is unlikely
to be sync. Most
On Tue, May 7, 2013 at 9:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, May 6, 2013 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote:
The only thing that's different about XHR is that the first step in my
list lives in one function, and the other steps live in another
function.
I'd be worried about letting any resolved URL to hold a reference to
the Blob. We are playing very fast and loose with URLs in Gecko and
it's never been intended that they hold on to any resources of
significant size.
/ Jonas
On Tue, May 7, 2013 at 1:34 PM, Glenn Maynard gl...@zewt.org wrote:
Fwiw, to the extent it may be helpful when it comes to spec writing, here
are some quick-n-dirty thoughts about how some approximation of the
'autorevoke' behavior could be implemented in chromium.
1) Extend the lifetime of the PublicBlobURL registration until *after* the
last latchee has
On Tue, May 7, 2013 at 2:54 PM, Jonas Sicking jo...@sicking.cc wrote:
I'd be worried about letting any resolved URL to hold a reference to
the Blob. We are playing very fast and loose with URLs in Gecko and
it's never been intended that they hold on to any resources of
significant size.
That
On Tue, May 7, 2013 at 4:54 PM, Jonas Sicking jo...@sicking.cc wrote:
I'd be worried about letting any resolved URL to hold a reference to
the Blob. We are playing very fast and loose with URLs in Gecko and
it's never been intended that they hold on to any resources of
significant size.
On Sun, May 5, 2013 at 5:37 PM, Jonas Sicking jo...@sicking.cc wrote:
What we do is that we
1. Resolve the URL against the current base URL
2. Perform some security checks
3. Kick off a network fetch
4. Return
Okay. So that fails for XMLHttpRequest :-( But if we made it part of
resolve that
On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, May 5, 2013 at 5:37 PM, Jonas Sicking jo...@sicking.cc wrote:
What we do is that we
1. Resolve the URL against the current base URL
2. Perform some security checks
3. Kick off a network fetch
4. Return
Okay.
On Mon, May 6, 2013 at 5:45 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren ann...@annevk.nl wrote:
Okay. So that fails for XMLHttpRequest :-(
What do you mean? Those are the steps we take for XHR requests too.
So e.g. open() needs to do URL parsing
On Mon, May 6, 2013 at 7:57 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, May 6, 2013 at 5:45 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren ann...@annevk.nl
wrote:
Okay. So that fails for XMLHttpRequest :-(
What do you mean? Those
On Wed, May 1, 2013 at 5:16 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, May 1, 2013 at 7:01 PM, Eric U er...@google.com wrote:
Hmm...now Glenn points out another problem: if you /never/ load the
image, for whatever reason, you can still leak it. How likely is that
in good code, though?
On Fri, May 3, 2013 at 6:55 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, May 2, 2013 at 12:53 AM, Jonas Sicking jo...@sicking.cc wrote:
It actually has turned out to be surprisingly easy in Gecko. But I
realize the same might not be true everywhere.
Can we have a description of this
On Sun, May 5, 2013 at 7:37 PM, Jonas Sicking jo...@sicking.cc wrote:
What we do is that we
1. Resolve the URL against the current base URL
2. Perform some security checks
3. Kick off a network fetch
4. Return
Note that no actual network activity happens here. That is all being
done on
Oops, forgot this was sitting here.
On Fri, May 3, 2013 at 8:55 AM, Anne van Kesteren ann...@annevk.nl wrote:
Glenn has at times suggested we could make a pertinent reference to
the Blob object from the URL object you get from the parsing. That
might work, but requires some special casing of
On Thu, May 2, 2013 at 12:53 AM, Jonas Sicking jo...@sicking.cc wrote:
But if we can figure out this problem, then my proposal would be to
add a new method which has a nicer name than createObjectURL as to
encourage authors to use that and have fewer leaks.
Yeah, I've been thinking the same
At the recent TPAC for Working Groups held in San Jose, Adrian Bateman, Jonas
Sicking and I spent some time taking a look at how to remedy what the spec.
says today about Blob URLs, both from the perspective of default behavior and
in terms of what correct autoRevoke behavior should be. This
On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan a...@mozilla.com wrote:
At the recent TPAC for Working Groups held in San Jose, Adrian Bateman, Jonas
Sicking and I spent some time taking a look at how to remedy what the spec.
says today about Blob URLs, both from the perspective of default
On Wed, May 1, 2013 at 4:25 PM, Eric U er...@google.com wrote:
On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan a...@mozilla.com wrote:
Switching the default to false would enable IE, Chrome, andFirefox to have
interoperability with URL.createObjectURL(blobArg), though such a default
places
On Wed, May 1, 2013 at 5:36 PM, Arun Ranganathan a...@mozilla.com wrote:
2a. To meticulously special-case Blob URLs, per Bug 17765 [4]. This calls
for a synchronous step attached to wherever URLs are used to peg Blob URL
data at fetch, so that the chance of a concurrent revocation doesn't
On Wed, May 1, 2013 at 4:53 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 1, 2013 at 4:25 PM, Eric U er...@google.com wrote:
On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan a...@mozilla.com wrote:
Switching the default to false would enable IE, Chrome, andFirefox to
have
On Wed, May 1, 2013 at 7:01 PM, Eric U er...@google.com wrote:
Hmm...now Glenn points out another problem: if you /never/ load the
image, for whatever reason, you can still leak it. How likely is that
in good code, though? And is it worse than the current state in good
or bad code?
I
25 matches
Mail list logo
