On 7/15/16 6:33 AM, Henri Sivonen wrote:
While I've been looking at other things, have we already gained an
object that tracks the load of a document all the way from when the
navigation starts at link click through redirects before the document
object exists?
Sort of. There's the LoadInfo.
-
On Fri, May 20, 2016 at 5:56 PM, Boris Zbarsky wrote:
> Background: We have a problem right now where the thing representing a
> "collection of loads" (a loadgroup) is attached to a docshell, not an
> individual document.
Slightly off-topic but:
The notion of attaching load or loadingness into t
On 7/7/16 6:33 AM, Anne van Kesteren wrote:
On Fri, May 20, 2016 at 4:56 PM, Boris Zbarsky wrote:
2) Create the loadgroup when we're starting the document request. The
channel would just keep it alive while it's active; if we end up creating a
document, the document can grab it from the chann
On Fri, May 20, 2016 at 4:56 PM, Boris Zbarsky wrote:
> 2) Create the loadgroup when we're starting the document request. The
> channel would just keep it alive while it's active; if we end up creating a
> document, the document can grab it from the channel and store it. This
> might just work
On May 20, 2016 6:14 PM, "Jonas Sicking" wrote:
> That doesn't sound good. We should give each worker its own loadgroup.
> Independent of if it's a dedicated, shared or service worker.
>
> Or is there a reason to share loadgroup with the document that I'm
missing?
Not sure. I think it's been tha
On Fri, May 20, 2016 at 4:04 PM, Ben Kelly wrote:
> On May 20, 2016 6:14 PM, "Jonas Sicking" wrote:
>> That doesn't sound good. We should give each worker its own loadgroup.
>> Independent of if it's a dedicated, shared or service worker.
>>
>> Or is there a reason to share loadgroup with the doc
On Fri, May 20, 2016 at 12:28 PM, Ben Kelly wrote:
> On Fri, May 20, 2016 at 3:12 PM, Jonas Sicking wrote:
>>
>> On Fri, May 20, 2016 at 8:04 AM, Ben Kelly wrote:
>> > On Fri, May 20, 2016 at 10:56 AM, Boris Zbarsky
>> > wrote:
>> >
>> >> Thoughts? Any obvious problems with this plan?
>> >
>>
On Fri, May 20, 2016 at 3:12 PM, Jonas Sicking wrote:
> On Fri, May 20, 2016 at 8:04 AM, Ben Kelly wrote:
> > On Fri, May 20, 2016 at 10:56 AM, Boris Zbarsky
> wrote:
> >
> >> Thoughts? Any obvious problems with this plan?
> >
> > We have the concept of network requests made from workers not a
On Fri, May 20, 2016 at 8:04 AM, Ben Kelly wrote:
> On Fri, May 20, 2016 at 10:56 AM, Boris Zbarsky wrote:
>
>> Thoughts? Any obvious problems with this plan?
>
> We have the concept of network requests made from workers not associated
> with a single document. For example, SharedWorker attache
On 5/20/16 11:04 AM, Ben Kelly wrote:
We have the concept of network requests made from workers not associated
with a single document. For example, SharedWorker attached to multiple
documents or a ServiceWorker servicing a push event. In theory we want the
same load grouping behavior to abort r
On 5/20/16 11:28 AM, smaug wrote:
(1) vs (2) isn't quite clear to me though. Do you mean with (2) that
docshell wouldn't have any loagroup, but a channel?
No. I mean that the docshell would have a loadgroup. When you navigate
a docshell it would create the new channel, create a _new_ loadgro
On 05/20/2016 05:56 PM, Boris Zbarsky wrote:
Background: We have a problem right now where the thing representing a "collection
of loads" (a loadgroup) is attached to a docshell, not an
individual document. This causes issues like loads started from unload events
being blamed on the new page a
Background: We have a problem right now where the thing representing a
"collection of loads" (a loadgroup) is attached to a docshell, not an
individual document. This causes issues like loads started from unload
events being blamed on the new page and whatnot, though it's possible
that loadinf
On Fri, May 20, 2016 at 10:56 AM, Boris Zbarsky wrote:
> Thoughts? Any obvious problems with this plan?
>
We have the concept of network requests made from workers not associated
with a single document. For example, SharedWorker attached to multiple
documents or a ServiceWorker servicing a pus
14 matches
Mail list logo
