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

26 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.

--
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.



--
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, 9:10:34 AM11/28/17
to Marijn Kruisselbrink, Kentaro Hara, platform-architecture-dev, Daniel Cheng, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
Good points. Maybe the practical way here would be to start from classes of tasks that browser are already reordering (e.g., timers, loading tasks) and extend the same flexibility to other things over time if/when necessary.

- Sami


- 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, 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.
--
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 28, 2017, 2:55:03 PM11/28/17
to Sami Kyostila, Marijn Kruisselbrink, platform-architecture-dev, Daniel Cheng, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
Thanks Marjin for the detailed thoughts! That's a great point.


On Tue, Nov 28, 2017 at 6:10 AM, Sami Kyostila <skyo...@chromium.org> wrote:
Good points. Maybe the practical way here would be to start from classes of tasks that browser are already reordering (e.g., timers, loading tasks) and extend the same flexibility to other things over time if/when necessary.

How would it be possible to change only the spec of JavaScript timers?

If we allow re-ordering JavaScript timer tasks (between related similar-origin frames), what's the point of specing the ordering of "frame1.contentWindow.cookieStore.set(...); frame2.contentWindow.cookieStore.set(...);"? There is no guarantee about which statement are executed first.

If I'm not missing something, the spec change needs to be all or nothing. And, after reading Marjin's email, I begin to realize that changing all the specs would not be a viable option. Then we'll probably need to keep the current spec?

Stepping back, would there really be many benefits in allowing re-ordering tasks between related similar-origin frames? In other words, would there be many cases where we want to throttle out-of-view, related similar-origin frames...?


 

- Sami


- 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.

--
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.



--
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.

--
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, 3:13:48 PM11/28/17
to Kentaro Hara, Marijn Kruisselbrink, platform-architecture-dev, Daniel Cheng, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
ti 28. marrask. 2017 klo 19.55 Kentaro Hara <har...@chromium.org> kirjoitti:
Thanks Marjin for the detailed thoughts! That's a great point.


On Tue, Nov 28, 2017 at 6:10 AM, Sami Kyostila <skyo...@chromium.org> wrote:
Good points. Maybe the practical way here would be to start from classes of tasks that browser are already reordering (e.g., timers, loading tasks) and extend the same flexibility to other things over time if/when necessary.

How would it be possible to change only the spec of JavaScript timers?

If we allow re-ordering JavaScript timer tasks (between related similar-origin frames), what's the point of specing the ordering of "frame1.contentWindow.cookieStore.set(...); frame2.contentWindow.cookieStore.set(...);"? There is no guarantee about which statement are executed first.

If I'm not missing something, the spec change needs to be all or nothing. And, after reading Marjin's email, I begin to realize that changing all the specs would not be a viable option. Then we'll probably need to keep the current spec?

Stepping back, would there really be many benefits in allowing re-ordering tasks between related similar-origin frames? In other words, would there be many cases where we want to throttle out-of-view, related similar-origin frames...?

I'm not sure I follow your example -- there are no timer tasks in it?

My completely naive idea for doing this just for JavaScript timers is to specify a new task source for them (or change the semantics of the existing one -- not sure if it's shared with other things) and spell out an algorithm that enqueues those tasks on a per-frame queue instead of the global one.

- Sami



 

- Sami


- 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, 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.

--
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 28, 2017, 5:02:34 PM11/28/17
to Sami Kyostila, Marijn Kruisselbrink, platform-architecture-dev, Daniel Cheng, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
Sorry, my question was a bit off the point -- I realized that my concern boils down to (simply) whether it's okay to reorder JavaScript timers (regardless of cookieStore.set()).

Think about the following example:

// main frame
setTimeout(function() { alert("aaa"); });
iframe.contentWindow.func();

// iframe
function func() {
  setTimeout(function() { alert("bbb"); });
}

If the order of JavaScript timers in related similar-origin iframes is not guaranteed, alert("bbb") may run before alert("aaa").

Ordinary developers wouldn't pay much attention to on what frames their functions are running. Then in practice, "setTimeout in related similar-origin iframes may be reordered" would mostly mean "setTimeout may be reordered". I *guess* the behavior would be confusing.

Given that related similar-origin iframes are scriptable with each other, a straightforward semantics would be that the task order is guaranteed in the related similar-origin iframes.





 

- Sami


- 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.

--
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.



--
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.

--
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, Tokyo, Japan

Sami Kyostila

unread,
Nov 29, 2017, 6:47:27 AM11/29/17
to Kentaro Hara, Marijn Kruisselbrink, platform-architecture-dev, Daniel Cheng, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
ti 28. marrask. 2017 klo 22.02 Kentaro Hara <har...@chromium.org> kirjoitti:
Sorry, my question was a bit off the point -- I realized that my concern boils down to (simply) whether it's okay to reorder JavaScript timers (regardless of cookieStore.set()).

Think about the following example:

// main frame
setTimeout(function() { alert("aaa"); });
iframe.contentWindow.func();

// iframe
function func() {
  setTimeout(function() { alert("bbb"); });
}

If the order of JavaScript timers in related similar-origin iframes is not guaranteed, alert("bbb") may run before alert("aaa").

Ordinary developers wouldn't pay much attention to on what frames their functions are running. Then in practice, "setTimeout in related similar-origin iframes may be reordered" would mostly mean "setTimeout may be reordered". I *guess* the behavior would be confusing.

Given that related similar-origin iframes are scriptable with each other, a straightforward semantics would be that the task order is guaranteed in the related similar-origin iframes.

I think giving that ordering guarantee would restrict our opportunities to throttle tasks in offscreen frames too much. We currently honor it for similar-origin frames, but timers in cross-origin frames can run in an arbitrary order w.r.t. other frames of the same origin (e.g., imagine two cross-origin frames from the same origin and one of them is offscreen).

AFAIK Safari goes even further by throttling timers in all offscreen frames regardless of origin. Given that they were able to ship that change and there is a power benefit in doing so, I think I'd like to match it in Chrome and update the spec to allow for this. Does that sound reasonable?

- Sami






 

- Sami


- 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, 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.

--
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, Tokyo, Japan

Kentaro Hara

unread,
Nov 29, 2017, 12:49:42 PM11/29/17
to Sami Kyostila, Marijn Kruisselbrink, platform-architecture-dev, Daniel Cheng, Alexander Timin, Alex Clarke, Taiju Tsuiki, scheduler-dev, Hajime Hoshi, Yuki Shiino
On Wed, Nov 29, 2017 at 3:47 AM, Sami Kyostila <skyo...@chromium.org> wrote:


ti 28. marrask. 2017 klo 22.02 Kentaro Hara <har...@chromium.org> kirjoitti:
Sorry, my question was a bit off the point -- I realized that my concern boils down to (simply) whether it's okay to reorder JavaScript timers (regardless of cookieStore.set()).

Think about the following example:

// main frame
setTimeout(function() { alert("aaa"); });
iframe.contentWindow.func();

// iframe
function func() {
  setTimeout(function() { alert("bbb"); });
}

If the order of JavaScript timers in related similar-origin iframes is not guaranteed, alert("bbb") may run before alert("aaa").

Ordinary developers wouldn't pay much attention to on what frames their functions are running. Then in practice, "setTimeout in related similar-origin iframes may be reordered" would mostly mean "setTimeout may be reordered". I *guess* the behavior would be confusing.

Given that related similar-origin iframes are scriptable with each other, a straightforward semantics would be that the task order is guaranteed in the related similar-origin iframes.

I think giving that ordering guarantee would restrict our opportunities to throttle tasks in offscreen frames too much. We currently honor it for similar-origin frames, but timers in cross-origin frames can run in an arbitrary order w.r.t. other frames of the same origin (e.g., imagine two cross-origin frames from the same origin and one of them is offscreen).

AFAIK Safari goes even further by throttling timers in all offscreen frames regardless of origin. Given that they were able to ship that change and there is a power benefit in doing so, I think I'd like to match it in Chrome and update the spec to allow for this. Does that sound reasonable?

If other browsers and the spec community are happy about the change, I won't object to it :D



- Sami






 

- Sami


- 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.

--
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.



--
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.

--
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, 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.
Reply all
Reply to author
Forward
0 new messages