Per unit-of-related-similar-origin-browsing-contexts scheduler?

23 views
Skip to first unread message

Taiju Tsuiki

unread,
Oct 24, 2017, 3:47:22 AM10/24/17
to scheduler-dev, Hajime Hoshi, Yuki Shiino
Hi, scheduler-dev.

IIUC, we have one scheduler per LocalFrame, and tasks posted from different frames may be shuffled as they are queued to separate TaskQueues.
However, according to the html spec, there must be at most one event loop per unit of related similar origin browser contexts.
That means, we have to keep the task ordering when two same origin-domain iframes queued tasks each. I think the current set up of the scheduler and frames do not guarantee the ordering of such tasks.
Note that a group of same origin-domain may be changed dynamically by modifying document.domain.

So, to be compliant to the spec, IMO, we should update the scheduler granularity to, probably, per "scheme & eTLD+1", so that all potentially same origin-domain browsing contexts shares the same scheduler.
E.g.: "http://foo.example.com:8080" and "http://bar.example.com:80" have the same scheme ("http") and same eTLD+1 ("example.com").

WDYT?

Alex Clarke

unread,
Oct 24, 2017, 3:57:16 AM10/24/17
to Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
On 24 October 2017 at 08:47, Taiju Tsuiki <tz...@chromium.org> wrote:
Hi, scheduler-dev.

IIUC, we have one scheduler per LocalFrame, and tasks posted from different frames may be shuffled as they are queued to separate TaskQueues.
However, according to the html spec, there must be at most one event loop per unit of related similar origin browser contexts.
That means, we have to keep the task ordering when two same origin-domain iframes queued tasks each. I think the current set up of the scheduler and frames do not guarantee the ordering of such tasks.

Unless the scheduler decides to intervene (i.e. throttle some queues or prioritise compositor work) then tasks are executed in posting order regardless of which queue they're posted to. 

 
Note that a group of same origin-domain may be changed dynamically by modifying document.domain. 

So, to be compliant to the spec, IMO, we should update the scheduler granularity to, probably, per "scheme & eTLD+1", so that all potentially same origin-domain browsing contexts shares the same scheduler.
E.g.: "http://foo.example.com:8080" and "http://bar.example.com:80" have the same scheme ("http") and same eTLD+1 ("example.com").

WDYT?

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAFK_eqTS_G5KgmtvxMg-s9yXbjBAE5gP2NQf2BXQPZBuWfyKwA%40mail.gmail.com.

Sami Kyostila

unread,
Oct 24, 2017, 1:54:23 PM10/24/17
to Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
There's one case where ordering isn't guaranteed: delayed tasks don't respect the posting order constraint across multiple task queues. Normally this isn't a problem except in special cases (virtual time), but technically it means that taking a task queue and splitting it into two separate ones will affect task ordering even if everything else remains the same.

I think the larger issue is that we should not be providing any guarantee about task ordering across multiple task queues -- that's the whole point of decomposing tasks into distinct queues in the first place. I don't think the "at most one event loop" language contradicts this, but the difference is that we can have more than one task queue for a particular task source. I'm thinking we may want to change the spec to allow this since a lot of the scheduling flexibility comes from this level of control.

- Sami

ti 24. lokak. 2017 klo 8.57 'Alex Clarke' via scheduler-dev <schedu...@chromium.org> kirjoitti:
On 24 October 2017 at 08:47, Taiju Tsuiki <tz...@chromium.org> wrote:
Hi, scheduler-dev.

IIUC, we have one scheduler per LocalFrame, and tasks posted from different frames may be shuffled as they are queued to separate TaskQueues.
However, according to the html spec, there must be at most one event loop per unit of related similar origin browser contexts.
That means, we have to keep the task ordering when two same origin-domain iframes queued tasks each. I think the current set up of the scheduler and frames do not guarantee the ordering of such tasks.

Unless the scheduler decides to intervene (i.e. throttle some queues or prioritise compositor work) then tasks are executed in posting order regardless of which queue they're posted to. 

 
Note that a group of same origin-domain may be changed dynamically by modifying document.domain. 

So, to be compliant to the spec, IMO, we should update the scheduler granularity to, probably, per "scheme & eTLD+1", so that all potentially same origin-domain browsing contexts shares the same scheduler.
E.g.: "http://foo.example.com:8080" and "http://bar.example.com:80" have the same scheme ("http") and same eTLD+1 ("example.com").

WDYT?

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

To post to this group, send email to schedu...@chromium.org.

Alexander Timin

unread,
Oct 30, 2017, 1:55:41 PM10/30/17
to Sami Kyostila, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
On 24 October 2017 at 18:54, Sami Kyostila <skyo...@chromium.org> wrote:
There's one case where ordering isn't guaranteed: delayed tasks don't respect the posting order constraint across multiple task queues. Normally this isn't a problem except in special cases (virtual time), but technically it means that taking a task queue and splitting it into two separate ones will affect task ordering even if everything else remains the same.

I think the larger issue is that we should not be providing any guarantee about task ordering across multiple task queues -- that's the whole point of decomposing tasks into distinct queues in the first place. I don't think the "at most one event loop" language contradicts this, but the difference is that we can have more than one task queue for a particular task source. I'm thinking we may want to change the spec to allow this since a lot of the scheduling flexibility comes from this level of control.

- Sami


ti 24. lokak. 2017 klo 8.57 'Alex Clarke' via scheduler-dev <schedu...@chromium.org> kirjoitti:
On 24 October 2017 at 08:47, Taiju Tsuiki <tz...@chromium.org> wrote:
Hi, scheduler-dev.

IIUC, we have one scheduler per LocalFrame, and tasks posted from different frames may be shuffled as they are queued to separate TaskQueues.
However, according to the html spec, there must be at most one event loop per unit of related similar origin browser contexts.
That means, we have to keep the task ordering when two same origin-domain iframes queued tasks each. I think the current set up of the scheduler and frames do not guarantee the ordering of such tasks.

Unless the scheduler decides to intervene (i.e. throttle some queues or prioritise compositor work) then tasks are executed in posting order regardless of which queue they're posted to. 

 
Note that a group of same origin-domain may be changed dynamically by modifying document.domain. 

So, to be compliant to the spec, IMO, we should update the scheduler granularity to, probably, per "scheme & eTLD+1", so that all potentially same origin-domain browsing contexts shares the same scheduler.
E.g.: "http://foo.example.com:8080" and "http://bar.example.com:80" have the same scheme ("http") and same eTLD+1 ("example.com").

WDYT?

I feel that we want to change the spec here and give the scheduler ability to schedule frames independently. For example, we are thinking about throttling same-origin frames and this is prohibited by the current wording of the spec. I'd prefer to change the spec to something like "tasks with the same task source related to the same frame are posted to the same task queue". Are there any downsides to this approach? 

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

To post to this group, send email to schedu...@chromium.org.

Kentaro Hara

unread,
Oct 31, 2017, 6:53:29 AM10/31/17
to Alexander Timin, Sami Kyostila, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
On Mon, Oct 30, 2017 at 6:55 PM, Alexander Timin <alt...@chromium.org> wrote:
On 24 October 2017 at 18:54, Sami Kyostila <skyo...@chromium.org> wrote:
There's one case where ordering isn't guaranteed: delayed tasks don't respect the posting order constraint across multiple task queues. Normally this isn't a problem except in special cases (virtual time), but technically it means that taking a task queue and splitting it into two separate ones will affect task ordering even if everything else remains the same.

I think the larger issue is that we should not be providing any guarantee about task ordering across multiple task queues -- that's the whole point of decomposing tasks into distinct queues in the first place. I don't think the "at most one event loop" language contradicts this, but the difference is that we can have more than one task queue for a particular task source. I'm thinking we may want to change the spec to allow this since a lot of the scheduling flexibility comes from this level of control.

- Sami


ti 24. lokak. 2017 klo 8.57 'Alex Clarke' via scheduler-dev <schedu...@chromium.org> kirjoitti:
On 24 October 2017 at 08:47, Taiju Tsuiki <tz...@chromium.org> wrote:
Hi, scheduler-dev.

IIUC, we have one scheduler per LocalFrame, and tasks posted from different frames may be shuffled as they are queued to separate TaskQueues.
However, according to the html spec, there must be at most one event loop per unit of related similar origin browser contexts.
That means, we have to keep the task ordering when two same origin-domain iframes queued tasks each. I think the current set up of the scheduler and frames do not guarantee the ordering of such tasks.

Unless the scheduler decides to intervene (i.e. throttle some queues or prioritise compositor work) then tasks are executed in posting order regardless of which queue they're posted to. 

 
Note that a group of same origin-domain may be changed dynamically by modifying document.domain. 

So, to be compliant to the spec, IMO, we should update the scheduler granularity to, probably, per "scheme & eTLD+1", so that all potentially same origin-domain browsing contexts shares the same scheduler.
E.g.: "http://foo.example.com:8080" and "http://bar.example.com:80" have the same scheme ("http") and same eTLD+1 ("example.com").

WDYT?

I feel that we want to change the spec here and give the scheduler ability to schedule frames independently. For example, we are thinking about throttling same-origin frames and this is prohibited by the current wording of the spec. I'd prefer to change the spec to something like "tasks with the same task source related to the same frame are posted to the same task queue". Are there any downsides to this approach? 

Yeah, I think this is a reasonable proposal.

Our per-frame scheduler is violating the spec currently :)

 

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAFK_eqTS_G5KgmtvxMg-s9yXbjBAE5gP2NQf2BXQPZBuWfyKwA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAPG_qM6ypz38grhT10JHpV%2B30vBat62iSy0AVK4sycqm2FhgOA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAPuLczubrkEaivaFUBYi46rDL5i42muqFQivzDY%2BxsfwUTxGBg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to schedu...@chromium.org.

Kentaro Hara

unread,
Nov 1, 2017, 2:02:35 AM11/1/17
to Alexander Timin, Sami Kyostila, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
I chatted with tzik offline and understood the problem better.

Now I begin to think that the current spec makes sense; i.e., "there is at most one event loop per unit of related similar origin browser contexts."

For simplicity, let's forget about document.domain at the moment. Then the spec requires to implement a per-origin event loop, not a per-frame event loop.

A per-frame event loop is problematic (and thus our current per-frame scheduler is problematic) because it's sometimes not clear what frame we should post a task to. For example, consider the following example:

  // main frame
  iframe.contentWindow.func();

  // iframe
  function func() {
    doSomethingThatPostsATask();
  }

Should the task be posted to the main frame's event loop, or iframe's event loop? Once we implement PauseFrame and pause the iframe, should the task be paused, or not? I guess the answer is not clear.

The spec circumvents this problem by saying that one event loop should be shared among all same-origin frames. I think that this makes more sense (than going with the per-frame scheduler and specing how all tasks should be associated with frames). Then PauseFrame should become "PauseOrigin".

If we go that way, do you think that it will decrease the flexibility of the scheduler too much?



Sami Kyostila

unread,
Nov 1, 2017, 7:23:23 AM11/1/17
to Kentaro Hara, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
If we go with per-origin instead of per-frame scheduling, we can't do things like throttling out-of-view cross origin frames if one frame in that origin is still visible. Note that Safari is already doing this kind of throttling even for same origin frames so they're not following the spec either. I think we should change the text.

To your example, I'd expect that most of the time doSomethingThatPostsATask() can figure out which document it's associated with and resolve to a frame that way. Do you have counter-examples in mind?

- Sami

To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

To post to this group, send email to schedu...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.



--
Kentaro Hara, Tokyo, Japan

Kentaro Hara

unread,
Nov 1, 2017, 9:21:23 AM11/1/17
to Sami Kyostila, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
To your example, I'd expect that most of the time doSomethingThatPostsATask() can figure out which document it's associated with and resolve to a frame that way. Do you have counter-examples in mind?

For example, what would happen in the following case?

  // main frame
  let xhr = iframe.contentWindow.loadResource();
  xhr.onload = onloadHandler;

  // iframe (assume that this iframe is invisible)
  function loadResource() {
    let xhr = new XMLHttpRequest;
    xhr.open(...);  // This posts a loading task.
    return xhr;
  }

If the task is associated with the iframe's scheduler and the iframe is paused, the onloadHandler will not get called. Whether the onloadHandler gets called depends on whether the iframe is visible, which sounds confusing to me :/


If we go with per-origin instead of per-frame scheduling, we can't do things like throttling out-of-view cross origin frames if one frame in that origin is still visible.

I'm just curious but do we have many cases where we want to throttle same-origin out-of-view frames?


Note that Safari is already doing this kind of throttling even for same origin frames so they're not following the spec either. I think we should change the text.

I intuitively understand what you want to realize but I'm not quite sure how we can spec that behavior. Something like "Each realm (i.e., v8::Context) may have one event loop. A task should be posted to a relevant realm of a receiver object (i.e., xhr's relevant v8::Context)" ?


- Sami


To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

To post to this group, send email to schedu...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.



--
Kentaro Hara, Tokyo, Japan



--
Kentaro Hara, Tokyo, Japan

Sami Kyostila

unread,
Nov 1, 2017, 1:43:45 PM11/1/17
to Kentaro Hara, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
ke 1. marrask. 2017 klo 13.21 Kentaro Hara <har...@chromium.org> kirjoitti:
To your example, I'd expect that most of the time doSomethingThatPostsATask() can figure out which document it's associated with and resolve to a frame that way. Do you have counter-examples in mind?

For example, what would happen in the following case?

  // main frame
  let xhr = iframe.contentWindow.loadResource();
  xhr.onload = onloadHandler;

  // iframe (assume that this iframe is invisible)
  function loadResource() {
    let xhr = new XMLHttpRequest;
    xhr.open(...);  // This posts a loading task.
    return xhr;
  }

If the task is associated with the iframe's scheduler and the iframe is paused, the onloadHandler will not get called. Whether the onloadHandler gets called depends on whether the iframe is visible, which sounds confusing to me :/

The XMLHttpRequest is associated with the iframe's document, right? I agree that it's slightly surprising that it would be tied to the frame's visibility but it kind of makes sense.
 


If we go with per-origin instead of per-frame scheduling, we can't do things like throttling out-of-view cross origin frames if one frame in that origin is still visible.

I'm just curious but do we have many cases where we want to throttle same-origin out-of-view frames?

I don't have data, but one example I can think of is several ads from the same domain on a single page.
 


Note that Safari is already doing this kind of throttling even for same origin frames so they're not following the spec either. I think we should change the text.

I intuitively understand what you want to realize but I'm not quite sure how we can spec that behavior. Something like "Each realm (i.e., v8::Context) may have one event loop. A task should be posted to a relevant realm of a receiver object (i.e., xhr's relevant v8::Context)" ?

I don't know if event loop is the right thing to be multiplying here. We still only have one top-level event loop. The real difference is that there are per-frame task sources instead of them being per-event loop.

- Sami
 


- Sami


To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

To post to this group, send email to schedu...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.



--
Kentaro Hara, Tokyo, Japan



--
Kentaro Hara, Tokyo, Japan

Kentaro Hara

unread,
Nov 1, 2017, 9:02:25 PM11/1/17
to Sami Kyostila, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
On Thu, Nov 2, 2017 at 2:43 AM, Sami Kyostila <skyo...@chromium.org> wrote:


ke 1. marrask. 2017 klo 13.21 Kentaro Hara <har...@chromium.org> kirjoitti:
To your example, I'd expect that most of the time doSomethingThatPostsATask() can figure out which document it's associated with and resolve to a frame that way. Do you have counter-examples in mind?

For example, what would happen in the following case?

  // main frame
  let xhr = iframe.contentWindow.loadResource();
  xhr.onload = onloadHandler;

  // iframe (assume that this iframe is invisible)
  function loadResource() {
    let xhr = new XMLHttpRequest;
    xhr.open(...);  // This posts a loading task.
    return xhr;
  }

If the task is associated with the iframe's scheduler and the iframe is paused, the onloadHandler will not get called. Whether the onloadHandler gets called depends on whether the iframe is visible, which sounds confusing to me :/

The XMLHttpRequest is associated with the iframe's document, right? I agree that it's slightly surprising that it would be tied to the frame's visibility but it kind of makes sense.

Yeah, my worry is that throttling / pausing same-origin out-of-view iframes would have a real risk of breaking behaviors of in-view iframes.

 


If we go with per-origin instead of per-frame scheduling, we can't do things like throttling out-of-view cross origin frames if one frame in that origin is still visible.

I'm just curious but do we have many cases where we want to throttle same-origin out-of-view frames?

I don't have data, but one example I can think of is several ads from the same domain on a single page.
 


Note that Safari is already doing this kind of throttling even for same origin frames so they're not following the spec either. I think we should change the text.

I intuitively understand what you want to realize but I'm not quite sure how we can spec that behavior. Something like "Each realm (i.e., v8::Context) may have one event loop. A task should be posted to a relevant realm of a receiver object (i.e., xhr's relevant v8::Context)" ?

I don't know if event loop is the right thing to be multiplying here. We still only have one top-level event loop. The real difference is that there are per-frame task sources instead of them being per-event loop.

Makes sense.

Overall I think I understand your point :) Introducing per-frame task sources to the spec makes sense to me. My worry mentioned above is more about how to schedule tasks without starving other task queues, which seems orthogonal to whether we should add per-frame task sources or not.


 

- Sami
 


- Sami


To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

To post to this group, send email to schedu...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.



--
Kentaro Hara, Tokyo, Japan



--
Kentaro Hara, Tokyo, Japan



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

To post to this group, send email to schedu...@chromium.org.

Sami Kyostila

unread,
Nov 3, 2017, 1:29:02 PM11/3/17
to Kentaro Hara, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
to 2. marrask. 2017 klo 1.02 Kentaro Hara <har...@chromium.org> kirjoitti:
On Thu, Nov 2, 2017 at 2:43 AM, Sami Kyostila <skyo...@chromium.org> wrote:


ke 1. marrask. 2017 klo 13.21 Kentaro Hara <har...@chromium.org> kirjoitti:
To your example, I'd expect that most of the time doSomethingThatPostsATask() can figure out which document it's associated with and resolve to a frame that way. Do you have counter-examples in mind?

For example, what would happen in the following case?

  // main frame
  let xhr = iframe.contentWindow.loadResource();
  xhr.onload = onloadHandler;

  // iframe (assume that this iframe is invisible)
  function loadResource() {
    let xhr = new XMLHttpRequest;
    xhr.open(...);  // This posts a loading task.
    return xhr;
  }

If the task is associated with the iframe's scheduler and the iframe is paused, the onloadHandler will not get called. Whether the onloadHandler gets called depends on whether the iframe is visible, which sounds confusing to me :/

The XMLHttpRequest is associated with the iframe's document, right? I agree that it's slightly surprising that it would be tied to the frame's visibility but it kind of makes sense.

Yeah, my worry is that throttling / pausing same-origin out-of-view iframes would have a real risk of breaking behaviors of in-view iframes.

Safari already does this so it should be doable for us too.
 

 


If we go with per-origin instead of per-frame scheduling, we can't do things like throttling out-of-view cross origin frames if one frame in that origin is still visible.

I'm just curious but do we have many cases where we want to throttle same-origin out-of-view frames?

I don't have data, but one example I can think of is several ads from the same domain on a single page.
 


Note that Safari is already doing this kind of throttling even for same origin frames so they're not following the spec either. I think we should change the text.

I intuitively understand what you want to realize but I'm not quite sure how we can spec that behavior. Something like "Each realm (i.e., v8::Context) may have one event loop. A task should be posted to a relevant realm of a receiver object (i.e., xhr's relevant v8::Context)" ?

I don't know if event loop is the right thing to be multiplying here. We still only have one top-level event loop. The real difference is that there are per-frame task sources instead of them being per-event loop.

Makes sense.

Overall I think I understand your point :) Introducing per-frame task sources to the spec makes sense to me. My worry mentioned above is more about how to schedule tasks without starving other task queues, which seems orthogonal to whether we should add per-frame task sources or not.

Right, we definitely need to take starvation into account when setting the scheduling policy.

- Sami



 

- Sami
 


- Sami


To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

To post to this group, send email to schedu...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.



--
Kentaro Hara, Tokyo, Japan



--
Kentaro Hara, Tokyo, Japan



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

To post to this group, send email to schedu...@chromium.org.

Kentaro Hara

unread,
Nov 27, 2017, 11:45:12 PM11/27/17
to Sami Kyostila, platform-architecture-dev, Daniel Cheng, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
(Let me revive this thread...)

Do we have a concrete plan to change the spec in such a way that tasks from different similar-origin frames can be posted to different task queues?

I'm asking this because messages in Mojo are hitting a similar ordering issue. At today's arch-lead meeting, we discussed this and agreed that we should make the behavior consistent between Mojo's messages and tasks. In other words, if tasks are scheduled with a per-frame consistency, Mojo's messages should be scheduled with a per-frame consistency as well. If tasks are scheduled with a per-related-similar-origin consistency, Mojo's messages should be scheduled with a per-related-similar-origin consistency as well.

So, I'm curious what consistency we're planning to guarantee for tasks.

Thanks!






 

- Sami
 


- Sami


To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

To post to this group, send email to schedu...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.



--
Kentaro Hara, Tokyo, Japan



--
Kentaro Hara, Tokyo, Japan



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

To post to this group, send email to schedu...@chromium.org.

Sami Kyostila

unread,
Nov 28, 2017, 6:59:29 AM11/28/17
to Kentaro Hara, platform-architecture-dev, Daniel Cheng, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
I think I'd still want us to change the spec to allow for per-frame consistency. Who can help make that happen?

- Sami




 

- Sami
 


- Sami


To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

To post to this group, send email to schedu...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.



--
Kentaro Hara, Tokyo, Japan



--
Kentaro Hara, Tokyo, Japan



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

To post to this group, send email to schedu...@chromium.org.

Marijn Kruisselbrink

unread,
Nov 28, 2017, 8:31:54 AM11/28/17
to Sami Kyostila, Kentaro Hara, platform-architecture-dev, Daniel Cheng, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
I'd say you have a very steep uphill battle to fight to get anything like that changed in all the specs. For one it's not just a simple case of changing any one spec to have multiple event loops. You'd also have to go through each and every spec and method to figure out what exactly you know want the browser to be able to re-order. I.e. for the mojo ordering issue, you might want to let the browser re-order "frame1.contentWindow.cookieStore.set(...); frame2.contentWindow.cookieStore.set(...);", but what about "frame1.contentWindow.document.cookie = ...; frame2.contentWindow.document.cookie = ...", and what about literally every other API/attribute where ordering of method calls is somehow observable? And how are you going to explain to developers that now under certain situations the browser is (effectively) free to reorder their javascript statements? You're introducing a huge amount of unpredictability. Also generally web specs (at least lately) hugely favor explicitly defined behavior in order to make interoperability more feasible over leaving things undefined. For example the note in the infra spec regarding ordered sets at https://infra.spec.whatwg.org/#sets, even though requiring ordered sets/maps in general puts extra requirements on implementers it helps tremendously with improving interoperability on the web, reducing the risk of websites relying on behavior only present in a single web browser. I think similar reasoning applies here too: currently it's well defined in which order we execute javascript statements, even if those statements involve objects that happen to involve objects "owned" by different frames (note that it might not always be obvious at the point where methods are called if a method call will involve an object in a different frame). What you're proposing is getting rid of any hope of interoperability there, introducing race conditions literally everywhere something might involve multiple frames. That seems to go exactly opposite from out interoperability and footgun predictability goals.

You're not asking for a simple spec change, you're asking to change something fundamental on which literally everything any spec defines is based. You're pretty much asking to throw out the entire processing model of HTML, and starting over with something else.


- Sami





 

- Sami
 


- Sami


To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.