Intent to ship: Animation composite modes

Hi, As of some time this week or next I intend to turn composite modes for animations on by default for all channels. It has been developed behind the dom.animations-api.compositing.enabled preference which has been on in Nightly for 3~4 years now. This is expected to ship in Chrome 84 (intent

Intent to ship: Element.getAnimations() and Document.getAnimations()

Hi, In the next few days I intend to turn on the Element.getAnimations() and Document.getAnimations() functions by default for release channels. This feature allows developers to fetch and manipulate animations generated using Element.animate() as well as animations created using CSS Animations

Intent to ship: Web Animations implicit to/from keyframes and auto-removing redundant filling animations

Hi, As of some time next week (week of Mar 2) I intend to turn on the following two Web Animations API features by default for release channels: * Implicit to/from keyframes (e.g. elem.animate({ opacity: 0 }, 500) to fade out an element). * Automatically removing filling animations that have

Intent to implement: Automatically removing replaced filling Web Animations

*Summary:* Using the Web Animations API it is possible to unwittingly trigger indefinitely-filling animations in a manner that effectively leaks memory. Recently-specified automatic removal behavior requires user agents to remove animations that are fully overlapped by other filling animations and

Intent to unship: Web animations composite modes on keyframes

As per my recent "Intent to ship: Web Animations core interfaces"[1], we do not intend to ship Animation composite modes until various spec work has been completed. However, when we implemented this feature, although we implemented it behind a pref, we failed to turn off all the ways of accessing

Intent to ship: Web Animations core interfaces

As of 19 July or thereabouts, I intend to turn on the Web Animations core interfaces by default on all platforms. It has been developed behind the dom.animations-api.core.enabled preference. What is already shipping? * Animation interface with playback methods * Animation finish / cancel events

Re: Are there some lists of web sites which use vertical writing-mode?

On Fri, Apr 6, 2018 at 10:26 AM, Masayuki Nakano wrote: > Does somebody know some lists of web sites which use vertical > writing-mode? Unfortunately, I don't know web sites which use writing-mode > heavily even though I usually read web sites written in Japanese... > For

Intent to unship: SMIL accessKey support

Background: SMIL includes a feature for triggering animations based on keypresses: e.g. Proposal: In bug 1423098 I intend to remove this feature. Rationale: * Apart from Gecko, only Presto supports it. * accessKey has been the source of security issues in the past such as bug

Re: More Rust code

On Tue, Jul 11, 2017 at 11:34 PM, Jim Mathies wrote: > What's the debugging situation look like for Windows developers? I've heard > it's pretty painful. Can we step through rust code using common tools > (WinDBG/Visual Studio)? > You can set breakpoints and step through

Re: Intent to ship: Frames timing functions

Since sending this intent to ship, questions have been raised over the suitability of the frames() name.[1] In order to allow the standards discussion to play out without being bound by shipping implementations, Chrome have decided to abort shipping their implementation to the release channel for

Re: Objecting to some proposed editor changes

Hi Daniel, Thank you for your mail. On Tue, Mar 14, 2017 at 4:02 PM, glazou wrote: > 2. it forces to move to commands, while an API remains available > even if the corresponding command is disabled I'd like to understand this point. Perhaps we can follow up on

Re: Intent to implement: Frames timing functions

On Sat, Feb 25, 2017 at 1:09 AM, wrote: > On Thursday, February 23, 2017 at 9:09:58 AM UTC-6, Boris Chiou wrote: >> *Preference behind which this will be implemented*: I'm not sure. I think >> we don't need it because it is just a variant of the step timing function, >> and

Re: Intent to implement: Frames timing functions

On Fri, Feb 24, 2017 at 12:35 AM, Jeff Muizelaar wrote: > The linked bug suggests that Chrome implements this but this email suggests > it doesn't. What's the truth? There used to be a steps-middle timing function which is what the linked bug originally covered. Chrome

Re: Do we need to run web-platform-tests --manifest-update when touching existing tests?

On Fri, Feb 10, 2017 at 8:37 PM, James Graham wrote: >> Should we be requiring people to update the MANIFEST.json whenever >> they touch a file in testing/web-platform/tests (i.e. not just when >> they add/remove files)? > > > This is too much to ask of people; it was

Re: Is there somewhere to get a report of new test failures from a web-platform-tests sync?

On Fri, Feb 10, 2017 at 8:04 PM, James Graham wrote: > I don't know what triage-center is, but increasing the visibility of > failures in web-platform-tests is certainly something that I think I should > work on; we are currently letting compat problems slip through >

Is there somewhere to get a report of new test failures from a web-platform-tests sync?

Hi, Today I was digging through the test expectations in web-platform-tests/meta and came across some failure annotations for tests added to w-p-t by Blink engineers that were since synced to m-c. Looking into them, one of them turned out to be a real bug in our code.[1] Apart from being stoked

Do we need to run web-platform-tests --manifest-update when touching existing tests?

Hi, It seems like the MANIFEST.json for web platform tests now includes a checksum of test file contents. As a result, if you run './mach web-platform-tests --manifest-update yer' on a clean checkout of m-c you're likely to get a bunch of changes to MANIFEST.json showing up. Should we be

Re: Intent to implement: transitionstart event

On 2016/08/22 8:18, Mantaroh Yoshinaga wrote: Although this event is only defined in a very early editor's draft of CSS Transitions Level 2 (Level 1 is still a working draft) this event has already shipped in Edge[1]. Unfortunately, it appears the spec behavior does not agree with the Edge

Re: Intent to ship: Element.animate

On Tuesday, 19 April 2016 09:29:02 UTC+9, bbir...@mozilla.com wrote: > Full details are in bug 1245000 from comment 9 onwards > (https://bugzilla.mozilla.org/show_bug.cgi?id=). Err, https://bugzilla.mozilla.org/show_bug.cgi?id=1245000#c9. ___

Intent to ship: Element.animate

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

Re: Finding out if the main thread is currently animating

On 2015/10/30 0:57, David Rajchenbach-Teller wrote: On 29/10/15 16:32, Benoit Girard wrote: We've explored several different ways of measuring this. Several of these are in the tree. Generally what I have found the most useful is to measure how we're servicing the content' main thread. This

Re: Intent to implement: Frame Timing API

On 2015/05/12 4:58, Boris Zbarsky wrote: On 5/11/15 3:32 PM, Ehsan Akhgari wrote: You can have style like: ... And then time the painting/compositing of the said content. No, you can't. We explicitly forbid that, precisely because of side-channel timing attacks. dbaron has a good writeup

Re: Intent to implement: Frame Timing API

On 2015/04/28 10:43, Jonas Sicking wrote: Please make sure to do a security review so that this doesn't expose any sensitive information accidentally. In particular, is there any way to use this API to use :visited hacks along with timing information to see if a user has visited a particular

Re: What are your pain points when running unittests?

On 2015/03/13 7:51, Jonathan Griffin wrote: The A-Team is embarking on a project to improve the developer experience when running unittests locally. Is this about C++ unittests or about mochitests etc.? If it's the latter, most of my pain points would be around debugging B2G failures.

Re: What are the most important new APIs to document in Q3/Q4?

On 2014/06/26 22:09, Eric Shepherd wrote: Hi! The docs team is trying to build our schedule for the next quarter or two, and part of that is deciding which APIs to spend lots of our time writing about. I'd like to know what y'all think the most important APIs are for docs attention in the next

Re: using namespace

(2014/05/21 8:51), Robert O'Callahan wrote: Personally I find unified-build-related using-namespace errors are rare --- I've not encountered one yet. I'm not sure they're worth attempting to ameliorate. I wasted half a day recently due to a using namespace mozilla::layers in an unrelated file

Re: Intent to Implement: Web Animations API

Animation effect target? KeyframeEffect getFrames (Here ? = not sure if it's necessary, not nullable) On 2014-04-18, 1:23 AM, Brian Birtles wrote: Summary: Allow web authors to inspect/debug/control running CSS (and SVG) animations and create new animations Bug: https://bugzilla.mozilla.org

Intent to Implement: Web Animations API

Summary: Allow web authors to inspect/debug/control running CSS (and SVG) animations and create new animations Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=875219 Link: http://dev.w3.org/fxtf/web-animations/ Platform coverage: All platforms Estimated or target release: late 2014

Web Animations introduction at tomorrow's Rendering meeting

Hi, At tomorrow's Rendering meeting I'd like to briefly introduce the Web Animations work with the intent of getting some more Mozilla feedback. I've written up a brief introduction and identified some issues on the wiki: