On 11/04/2016 04:55 PM, Ben Kelly wrote:
I think we need to fix this issue as well. I think it could probably be
uplifted before requestIdleCallback() hits release, though.
https://bugzilla.mozilla.org/show_bug.cgi?id=1315260
I think also https://bugzilla.mozilla.org/show_bug.cgi?id=1313989 should be
fixed.
Some variant of https://bugzilla.mozilla.org/show_bug.cgi?id=1313864 would be
nice to have, but less critical.
On Thu, Nov 3, 2016 at 4:01 PM, Andreas Farre <fa...@mozilla.com> wrote:
As of 2016-11-7 I intend to turn requestIdleCallback on by default
(with the condition that
https://bugzilla.mozilla.org/show_bug.cgi?id=1314314 has landed). It
has been developed behind the dom.requestIdleCallback.enabled
preference. Other UAs shipping this or intending to ship it are Chrome
(shipping), Edge (public support).
This feature was previously discussed in this "intent to implement"
thread: https://groups.google.com/forum/#!msg/mozilla.dev.
platform/q6AQnTEeX6o/dqS48DbtAwAJ
Bug to turn on by default: https://bugzilla.mozilla.org/
show_bug.cgi?id=1314959
Link to standard: https://w3c.github.io/requestidlecallback/
Since 'Intent to Implement' was sent mainly clarifications of the spec
have been added. Differences standing out are:
* Callbacks are associated with Window instead of Document
* Opening up for future additions of scheduling strategies
* Added privacy section explaining how the fingerprinting of
requestIdleCallback is no worse than fingerprinting of
requestAnimationFrame
Cheers,
Andreas
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
