Re: PSA: some setTimeout()/setInterval() changes

2016-10-27 Thread Mike Taylor 

On 10/27/16 12:48 PM, Ben Kelly wrote:

On Thu, Oct 27, 2016 at 1:26 PM, Mike Taylor > wrote:

On 10/27/16 10:08 AM, Ben Kelly wrote:

The short story is that there should be very minimal observable
difference.


How do these changes compare with other browsers behavior (for the
web-observable effects)? Do you have any idea?


I honestly don't know how other browsers handle these edge cases.

I believe, however, our previous behavior of "freezing time" during a
sync xhr was unspec'd and probably unexpected.  I don't see anything in
xhr.spec.whatwg.org  about shifting timers
around.

The html spec references the "pause" concept for alert() modals:

https://html.spec.whatwg.org/#pause

Again, this says nothing specific about running pending code
synchronously when you leave the modal state.  It even encourages
experimentation around mitigating the impact of the modal on user
experience.

Not sure if that helps or not.  I tend to believe these changes won't
have a large compat impact since timers are already rather imprecise and
can be delayed for a number of reasons.


Cool, thanks -- something to keep an eye on for particularly weird bugs. :)

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: some setTimeout()/setInterval() changes

2016-10-27 Thread Ben Kelly 
On Thu, Oct 27, 2016 at 1:26 PM, Mike Taylor  wrote:

> On 10/27/16 10:08 AM, Ben Kelly wrote:
>
>> The short story is that there should be very minimal observable
>> difference.
>>
>
> How do these changes compare with other browsers behavior (for the
> web-observable effects)? Do you have any idea?


I honestly don't know how other browsers handle these edge cases.

I believe, however, our previous behavior of "freezing time" during a sync
xhr was unspec'd and probably unexpected.  I don't see anything in
xhr.spec.whatwg.org about shifting timers around.

The html spec references the "pause" concept for alert() modals:

https://html.spec.whatwg.org/#pause

Again, this says nothing specific about running pending code synchronously
when you leave the modal state.  It even encourages experimentation around
mitigating the impact of the modal on user experience.

Not sure if that helps or not.  I tend to believe these changes won't have
a large compat impact since timers are already rather imprecise and can be
delayed for a number of reasons.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: some setTimeout()/setInterval() changes

2016-10-27 Thread Mike Taylor 

Hey Ben,

On 10/27/16 10:08 AM, Ben Kelly wrote:

The short story is that there should be very minimal observable
difference.


How do these changes compare with other browsers behavior (for the 
web-observable effects)? Do you have any idea?


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: some setTimeout()/setInterval() changes

2016-10-27 Thread Ben Kelly 
Hey all,

Just FYI, I've landed a refactoring of how we suspend our timers in:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1303167

The short story is that there should be very minimal observable
difference.  The main changes you might see are:

1) Previously we shifted timers during things like sync xhr.  This made it
seem like "time stood still" for those timers.  If you had a timer in 1
second and did a sync xhr for 0.5 seconds, then the timer would fire 1
second after the sync xhr.

Now we don't shift timers and allow "time to pass" during things like sync
xhr.  So if you have a timer in 1 second and do a sync xhr for 0.5 seconds
then the timer will fire 0.5 seconds after the sync xhr.

2) When a modal dialog was closed we used to synchronously run all timers
that might have fired during the modal state.  We now fire these timers
asynchonously.  In addition, they may be subject ot the background timer
throttling.  So these timers will be slightly delayed compared to
previously behavior.

3) We now suspend timers in all child windows when a chrome modal dialog is
shown.  Previously it was possible for content windows to continue to run
timers when a chrome modal was open.  There was only a single test that
this change impacted.  This change makes the behavior consistent between
content and chrome modal dialogs.

The bug has all the gory details, but this change cleans up an error-prone
API and a secondary way of stopping timers.  We now have a single method
for suspending and resuming timers.

Please let me know if you run into any problems from these changes.

Thanks.

Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform