Finding out if the main thread is currently animating

To improve the Performance Stats API, I'm looking for a way to find out if we are currently animating something on the main thread. My definition of animating is pretty large, i.e. "will the user probably notice if some computation on the main thread lasts more than 32ms". Do we have a reliable

Re: Finding out if the main thread is currently animating

The main thread of the current chrome/content process. Indeed, animations are one of my two use cases, the other one being user-input latency, but I'm almost sure I know how to deal with the latter. Cheers, David On 29/10/15 14:32, Benjamin Smedberg wrote: > On the main thread of which

Re: Merge moved to Thursday 29th

I missed two commits for 44 branch. https://treeherder.mozilla.org/#/jobs?repo=fx-team=6b3c99e54177 Uplift requests will not help because they are string changes. On 2015/10/29 5:10, Sylvestre Ledru wrote: > Hello, > > Because we want to synchronize the release of 42 and 44 devedition (next >

Re: Merge moved to Thursday 29th

Please request the uplift. Under specific circumstances (like this one), we take string changes in aurora. Thanks Sylvestre Le 29/10/2015 13:39, Masatoshi Kimura a écrit : > I missed two commits for 44 branch. > https://treeherder.mozilla.org/#/jobs?repo=fx-team=6b3c99e54177 > Uplift requests

Re: Finding out if the main thread is currently animating

On the main thread of which process? Please consider non-"animation" use-cases. In particular, users do notice the latency of typing into edit boxes as much as anything else. So let's make sure that editing latency triggers this as much as a current animation. --BDS On 10/29/2015 9:14 AM,

Re: Merge moved to Thursday 29th

I'm also commented in the bug: If we're doing uplifts, I'm not sure we're winning by uplifting pre-landed strings. Either way, I think the risk assessment of the patch should be that of the actual patch that uses the strings, not "just adding strings". Also, I'd appreciate an ETA for the

Re: Finding out if the main thread is currently animating

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 measurement > is great because its measures how

Re: Finding out if the main thread is currently animating

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 measurement is great because its measures how responsive Firefox is not only for

Re: Intent to ship: WebVR

On Monday, October 26, 2015 at 9:39:57 PM UTC-4, Ehsan Akhgari wrote: > First things first, congratulations on getting this close! > > What's the status of the specification? I just had a quick skim and it > seems extremely light on details. The spec is still a draft, and the API is expected

Re: Intent to ship: WebVR

On Wednesday, October 28, 2015 at 11:38:26 AM UTC-4, Gervase Markham wrote: > On 26/10/15 19:19, Kearwood "Kip" Gilbert wrote: > > As of Oct 29, 2015 I intend to turn WebVR on by default for all > > platforms. It has been developed behind the dom.vr.enabled preference. > > A compatible API has

Re: Intent to ship: WebVR

On 2015-10-29 1:10 PM, vladi...@mozilla.com wrote: On Monday, October 26, 2015 at 9:39:57 PM UTC-4, Ehsan Akhgari wrote: First things first, congratulations on getting this close! What's the status of the specification? I just had a quick skim and it seems extremely light on details. The

Partial updates temporarily disabled for Nightly and Dev-Edition

We've temporarily disabled generation of partial updates for Nightly and Dev-Edition (Aurora) versions of Firefox. Given that Dev-Edition updates are currently frozen as part of our uplift process, the main impact of this is on Nightly users. We hope to have partial update generation re-enabled

Re: Collecting web platform features implementation status

Seems like this kind of died. I still would like to see this happening. Is this on somebody's agenda? On Tue, Jul 21, 2015 at 8:40 PM, Tom Schuster wrote: > I see 3 (now 4) old pull requests that are unmerged. > > On Tue, Jul 21, 2015 at 8:19 PM, Anthony Ricaud

Re: Intent to ship: WebVR

On 10/29/15 1:10 PM, vladi...@mozilla.com wrote: The intent to ship here is a bit premature; the intent is to pref it on in nightly & aurora, not ship it all the way to release. OK. The patches in the "enable it" bugs are enabling on all branches; we should probably scale that back to just

Re: Date, time, week, month and datetime attributes in the in Firefox

Carlos Valim Coragem schrieb: I asked this same question on channel #mozilla-br on IRC, a mozillian gave me this link: https://bugzilla.mozilla.org/show_bug.cgi?id=1069609 - the bug was opened on 09-18-2014, the last comment was day 07-24-2015, wondering if there was any progress on that.

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

Date, time, week, month and datetime attributes in the in Firefox

Hi my friends! I'm not sure where I can ask this question, so I'm sorry in advance :P I'm having trouble using the attributes in the : date, time, week, month and datetime - in Firefox. During a class in college, last Tuesday, the teacher taught HTML elements when several students, including

Re: Making tests e10s compatible

Thanks for this Blake. Somewhat related: for those of you using ESLint, I recently filed a bug to create a new custom ESLint rule that should help automatically detect CPOW usage in tests: https://bugzilla.mozilla.org/show_bug.cgi?id=1218412 On Thu, Oct 29, 2015 at 12:44 AM, Blake Kaplan

Re: Merge moved to Thursday 29th

Le 29/10/2015 02:11, Ehsan Akhgari a écrit : > On 2015-10-28 4:10 PM, Sylvestre Ledru wrote: >> Hello, >> >> Because we want to synchronize the release of 42 and 44 devedition (next >> Tuesday), >> we are planning to perform the merge tomorrow, Thursday. >> As a consequence, nightly = 45, aurora =

Re: Date, time, week, month and datetime attributes in the in Firefox

On Fri, Oct 30, 2015 at 10:25 AM, Ehsan Akhgari wrote: > On 2015-10-29 7:21 PM, Carlos Valim Coragem wrote: >> >> It seems that this problem only happens in the desktop version and not >> in >> mobile, I just did a test with the same webpage in version 34.0.1 of >>

Re: Date, time, week, month and datetime attributes in the in Firefox

On 2015-10-29 7:21 PM, Carlos Valim Coragem wrote: It seems that this problem only happens in the desktop version and not in mobile, I just did a test with the same webpage in version 34.0.1 of Firefox to Android and it worked! Your experience is expected. We have an implementation of

Re: Finding out if the main thread is currently animating

David Rajchenbach-Teller writes: > To improve the Performance Stats API, I'm looking for a way to find out > if we are currently animating something on the main thread. > > My definition of animating is pretty large, i.e. "will the user probably > notice if some computation on the main thread

Re: Finding out if the main thread is currently animating

On 2015-10-29 9:47 AM, David Rajchenbach-Teller wrote: The main thread of the current chrome/content process. Indeed, animations are one of my two use cases, the other one being user-input latency, but I'm almost sure I know how to deal with the latter. Out of curiosity, how are you planning