Intent to ship: Element.animate

[Brian Birtles]

In Firefox 48 I intend to turn Element.animate on by default.

We have been developing the Web Animations API behind the 
dom.animations-api.core.enabled preference and have introduced the 
dom.animations-api.element-api.enabled preference for the subset of the 
API that we intend to ship at this time.


Chrome have been shipping a very similar subset of the API starting with 
Chrome 36[1] and have recently updated their implementation to match the 
subset we plan to ship.[2]


WebKit[3] and Edge[4] both list this as "under consideration" although 
some implementation work has begun in WebKit.[5]


This feature was previously discussed in this "intent to implement" 
thread: 
https://groups.google.com/d/topic/mozilla.dev.platform/3EXBgp26rJs/discussion


Bug to turn on by default: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1245000
Link to standard: 
https://w3c.github.io/web-animations/#dom-animatable-animate


The subset of the API we intend to ship is described in the bug above, a 
summary of which I have copied to the end of this mail. We do not intend 
to ship the 'finished' promise at this time due to concern that this 
should use a cancelable promise.[6]


Best regards,

Brian

[1] https://www.chromestatus.com/features/4854343836631040, 
https://www.chromestatus.com/features/5633748733263872
[2] https://www.chromestatus.com/features/5650817352728576, 
https://www.chromestatus.com/features/5663463749713920

[3] https://webkit.org/status/#specification-web-animations
[4] 
https://developer.microsoft.com/en-us/microsoft-edge/platform/status/webanimationsjavascriptapi

[5] https://lists.webkit.org/pipermail/webkit-dev/2015-November/027771.html
[6] https://github.com/w3c/web-animations/issues/141


Proposed API subset:

enum AnimationPlayState { "idle", "pending", "running", "paused", 
"finished" };


// 'Animation' will not be exposed on the global unless Element.animate 
is called

interface Animation : EventTarget {
   attribute DOMString  id;
   attribute double?startTime;
   attribute double?currentTime;
   attribute double playbackRate;
  readonly attribute AnimationPlayState playState;
  readonly attribute Promise ready;
   attribute EventHandler   onfinish;
   attribute EventHandler   oncancel;
  void cancel ();
  void finish ();
  void play ();
  void pause ();
  void reverse ();
};

enum FillMode {
  "none",
  "forwards",
  "backwards",
  "both",
  "auto"
};

enum PlaybackDirection {
  "normal",
  "reverse",
  "alternate",
  "alternate-reverse"
};

dictionary AnimationEffectTimingProperties {
  double  delay = 0.0;
  double  endDelay = 0.0;
  FillModefill = "auto";
  double  iterationStart = 0.0;
  unrestricted double iterations = 1.0;
  (unrestricted double or DOMString)  duration = "auto";
  PlaybackDirection   direction = "normal";
  DOMString   easing = "linear";
};

// These members are read but not implemented
dictionary KeyframeEffectOptions : AnimationEffectTimingProperties {
  IterationCompositeOperation iterationComposite = "replace";
  CompositeOperation  composite = "replace";
  DOMString   spacing = "distribute";
};

dictionary KeyframeAnimationOptions : KeyframeEffectOptions {
  DOMString id = "";
};

[NoInterfaceObject]
interface Animatable {
  Animation animate(object? frames,
optional (unrestricted double or 
KeyframeAnimationOptions)

  options);
};

Element implements Animatable;
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Stability

[Nicholas Nethercote]

On Mon, Apr 18, 2016 at 10:34 AM, Kartikaya Gupta  wrote:
>
> My view is that if we have a lot of bugs and regressions, time spent
> investigating and fixing those naturally acts as a backflow to new feature
> work, which prevents the introduction of even more bugs and regressions. So
> really time spent investigating these issues is good in that it encourages
> a self-correcting cycle, rather than just adding more regressions and work
> for everybody that will never get done.
>
> Of course, the tradeoff is that we have this goals system where you have to
> state up front what you are going to do in a quarter and that makes it
> harder to justify spending time on these other issues that often take a lot
> of time as you poke around in unfamiliar code. Also falling behind on
> features means we fall behind other browsers from a user perspective. My
> interpretation of the push on quality, though, is that this is correct
> tradeoff to make for us at this time, because great bug-free experiences
> are more useful to us right now than a pile of half-baked features.

This is a good opportunity to spruik the nascent Project Uptime
(https://wiki.mozilla.org/Platform/Uptime) which aims to improve
stability. I'd like to highlight one sentence in David Bryant's
announcement:

"The overall responsibility to hit our stability target is something
that falls on the entire platform organization, and in terms of
priority, stability is second only to shipping e10s."

In this context "stability" refers to crash rate, but with a little
bit of flexibility and imagination we can extend it to things that
adversely affect the user experience in similar ways, such as bad GC
pauses.

I understand that the quarterly deliverables system can distract from
this kind of work. I would hope that all Platform managers would be
flexible enough that if one of their employees said "I'm thinking
about chasing this cluster of crashes for the next week or two, which
may cause me to slip on a deliverable" they would be open to that
suggestion.

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

Re: PSA: Cancel your old Try pushes

[Kartikaya Gupta]

On Apr 17, 2016 1:55 PM, "Steve Fink"  wrote:
>
> Generally speaking, Firefox's stability has not been good for me for 2-3
months. I'd like to file a bug, but I've already used up my quota of
unactionable bugs, and if I dug into all of my idiosyncratic issues I'd
never get any work done.

Also (and I don't mean to single out sfink; I've heard similar things from
other people, and have been guilty of this myself) - filling bugs and
digging into issues *is* work, so saying "I'd never get any work done"
really means "I won't be able to get around to what I'm supposed to be
doing instead".

My view is that if we have a lot of bugs and regressions, time spent
investigating and fixing those naturally acts as a backflow to new feature
work, which prevents the introduction of even more bugs and regressions. So
really time spent investigating these issues is good in that it encourages
a self-correcting cycle, rather than just adding more regressions and work
for everybody that will never get done.

Of course, the tradeoff is that we have this goals system where you have to
state up front what you are going to do in a quarter and that makes it
harder to justify spending time on these other issues that often take a lot
of time as you poke around in unfamiliar code. Also falling behind on
features means we fall behind other browsers from a user perspective. My
interpretation of the push on quality, though, is that this is correct
tradeoff to make for us at this time, because great bug-free experiences
are more useful to us right now than a pile of half-baked features.

Cheers,
kats

>
>
> On 04/16/2016 08:32 PM, Nicholas Nethercote wrote:
>>
>> I use T-pushes on try a lot, where I build on all platforms (debug and
>> opt) but run tests only on one platform (debug and opt), usually
>> Linux64. I.e.: "try: -b do -p all -u none[x64] -t none[x64]".
>
> I think you meant "try: -b do -p all -u all[x64] -t all[x64]".
>
>
> ___
> 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

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

On 4/15/16 2:12 AM, Jason Duell wrote:

> Focusing on third-party session cookies is an interesting idea.
> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
> content problems. Much later, we could consider sessionizing even HTTPS
> third-party cookies.
>

How about we sessionize only 3rd party HTTP cookies from sites that are on
our tracking protection list?  That seems the most targeted way to
encourage ad networks to bump up to HTTPS with a minimal amount of
collateral damage to other users of 3rd party HTTP cookies.


The IAB recently announced a "LEAN Ads" initiative [1]: Light, Encrypted 
(HTTPS), Ad Choice supported, and Non-invasive.


When the IAB agrees ad networks should use HTTPS, clearing HTTP cookies 
from third parties and/or sites on the Tracking Protection list becomes 
an easier sell, policy-wise. We're not talking about blocking cookies or 
content, just reducing the cookie lifetime.



[1] http://www.iab.com/news/lean/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[Mike Conley]

If I had to guess, I'd say that it's just consuming more and more memory as
more and more nodes are getting added to the DOM, and more AngularJS stuff
gets instantiated.

I would put good money on those multi-second pauses being attempts to GC /
CC


On 16 April 2016 at 05:50, Gijs Kruitbosch  wrote:

> On 16/04/2016 01:24, Steve Fink wrote:
>
>> Doesn't everyone keep a tab open to their try page? eg I have
>> https://treeherder.mozilla.org/#/jobs?repo=try=sf...@mozilla.com
>> open all the time.
>>
>
> No. Treeherder is too resource-intensive to keep open for long periods of
> time. I tend to see multi-second pauses on my regular browser (beta) on
> Windows. No idea what it does, but it's not good.
>
> ~ Gijs
>
> ___
> 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