Re: Finding out if the main thread is currently animating

[David Rajchenbach-Teller]

Recall that I'm not interested in measuring all latency, only (for the
time being) latency caused by JS code executing on the main thread or
waiting for a CPOW. This simplifies a lot the implementation (when I
execute JS code, I just need to check whether I'm currently dealing with
a user-issued event), but unfortunately doesn't cover your use-case.

I'll be happy to brainstorm your use-case afterwards, but this sounds
like an entirely different set of challenges.

Cheers,
 David

On 30/10/15 02:35, Ehsan Akhgari wrote:
> Out of curiosity, how are you planning to measure input latency?  Based
> on event timestamps?
> 
> The reason I'm asking is that with e10s, I sometimes see long (even
> multi-second!) delays between for example clicking the new tab button,
> or for the title of a new tab to appear after the tab being initially
> painted) that are very visible to the user, and can't be detected that
> way.  I think it would be nice to come up with a set of user actions in
> the primary UI and manually measure their delay based on the knowledge
> that we have about the asynchronous nature of their implementation.
> 
> Cheers,
> Ehsan


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Xidorn Quan]

On Fri, Oct 30, 2015 at 3:57 PM, Jonas Sicking  wrote:
> On Thu, Oct 29, 2015 at 9:38 PM, Xidorn Quan  wrote:
>> 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
 Firefox to Android and it worked!
>>>
>>>
>>> Your experience is expected.  We have an implementation of these form
>>> controls on Android, but not on desktop.  We have been waiting for UX specs
>>> for this feature on desktop, as you have discovered.  :-)
>>
>> We really should push UX people to have that done. It is a pain that
>> those things are not usable. Having those input types will save plenty
>> of time for frontend developers to make their apps support Firefox.
>> (Otherwise, they might just drop the Firefox support.)
>
> I don't think having a good UX is the main blocker here.
>
> The main blocker, IMO, is that unless web authors can style these
> controls to integrate well with the look and feel of the rest of their
> website, they won't be interested in using these controls.
>
> I.e. unless we make these stylable, simply using jQuery UI will
> provide websites and users with a better experience.

Authors sometimes just want something usable. It doesn't matter if it
is not stylable, or it doesn't fit in the UI. When they really need to
start caring about such things, they can switch to use jQuery UI then.

At least, some simple, tooling web apps do not need any styling at
all. They just need something sensible enough to use. We should enable
such usage without pushing them to use jQuery UI. (Actually, people
could sometimes prefer the system UI rather than the custom things
like jQuery UI.)

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

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

[Jonas Sicking]

On Fri, Oct 30, 2015 at 12:36 AM, Xidorn Quan  wrote:
> Authors sometimes just want something usable. It doesn't matter if it
> is not stylable, or it doesn't fit in the UI. When they really need to
> start caring about such things, they can switch to use jQuery UI then.

I think this is true for a *very* small number of authors. Small
enough that we should spend our time on more impactful things.

Look at the tooling websites that we use within mozilla. bugzilla.m.o,
treeherder.m.o, wiki.m.o and MDN all care about a pleasant look and
feel.

Also remember that jQuery UI also works fine for websites that "just
wants something usable".

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

Sheriffing Newsletter October Edition

[Carsten Book]

Hi,

To give a little insight into our work and make our work more visible to
our Community we decided to create a monthly report of what's going on in
the Sheriffs Team.

If you have questions or feedback, just let us know!

In case you don't know who the sheriffs are, or to check if there are
current issues on the tree, see:
https://sheriffs.etherpad.mozilla.org/sheriffing-notes

Topics of this month!

1. How-To article of the month
2. Get involved
3. Statistics
4. Orange Factor
5. Meeting notes
6. Contact

1. How-To article of the month and notable things!

Ever had a question about checking patches in, getting them backed out, or
any other related topic? The Sheriff Team is here to help! We usually hang
out in #developers on Mozilla's IRC network, and you can find the current
sheriff on duty by looking for the "|sheriffduty" tag on the name. We try
to rotate in order to cover every time zone. You can also reach us by email
via sheriffs at mozilla dot com.

2. Get involved!

Are you interested in helping out by becoming a Community Sheriff? Let us
know!

3. Statistics

Intermittent Bugs filed this month [1]: 312

and 17 Bugs of this Closed this Month [2]

For Tree Closing times and reasons see:
http://futurama.theautomatedtester.co.uk/

4. Orange Factor

Current Orangefactor [3]: 13.83

5. Meeting Notes:

We Sheriffs hold regular meetings. Our notes can be found here:

https://public.etherpad-mozilla.org/p/Sheriff-meeting-26oct

6.  How to contact us

There are a lot of ways to contact us. The fastest one is to contact
the sheriff on duty (the one with the |sheriffduty tag on their nick
:) or by emailing sheriffs @ mozilla dot org.

Cheers,

Tomcat

[1] http://mzl.la/1P9eZl8
[2] http://mzl.la/1XDtaBZ
[3] https://brasstacks.mozilla.com/orangefactor/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding out if the main thread is currently animating

[David Rajchenbach-Teller]

Note that I'm looking for a way to track this across the entire process,
not a single document. I'd rather avoid having to track all documents
(both XUL and HTML) in the process if I can find a simpler solution.

On 30/10/15 01:18, Brian Birtles wrote:
> For CSS animations/transitions (not including SVG SMIL animations), you
> could use:
> 
>   document.timeline.getAnimations().some(
> anim => anim.playState == 'running')
> 
> (Soon to become just document.getAnimations())
> 
> We could likewise just check if the DocumentTimeline is observing the
> refresh driver since we should stop doing that when CSS
> animations/transitions are at rest.
> 
> For rAF animations we could use the the js::NotifyAnimationActivity
> information? Or else look for registered frame request callbacks?
> 
> I think we could probably detect SVG SMIL animations too, if needed
> (perhaps by exposing the mRegisteredWithRefreshDriver member of
> nsSMILAnimationController although that might be too broad).


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding out if the main thread is currently animating

[David Rajchenbach-Teller]

Yes, that's also my guess. I'd appreciate if someone could confirm that.
Also, I haven't found a public API for this, so I'm digging in the
source of the refresh driver, and I haven't found confirmation yet.

Cheers,
 David

On 30/10/15 02:33, Karl Tomlinson wrote:
> David Rajchenbach-Teller writes:
> I would guess that our main thread animations all run off a single
> 60 Hz throttle, which I assume is the RefreshDriver.  If that
> throttle has no jobs scheduled to run, then I expect there are no
> animations in progress.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jonas Sicking]

On Thu, Oct 29, 2015 at 9:38 PM, Xidorn Quan  wrote:
> 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
>>> Firefox to Android and it worked!
>>
>>
>> Your experience is expected.  We have an implementation of these form
>> controls on Android, but not on desktop.  We have been waiting for UX specs
>> for this feature on desktop, as you have discovered.  :-)
>
> We really should push UX people to have that done. It is a pain that
> those things are not usable. Having those input types will save plenty
> of time for frontend developers to make their apps support Firefox.
> (Otherwise, they might just drop the Firefox support.)

I don't think having a good UX is the main blocker here.

The main blocker, IMO, is that unless web authors can style these
controls to integrate well with the look and feel of the rest of their
website, they won't be interested in using these controls.

I.e. unless we make these stylable, simply using jQuery UI will
provide websites and users with a better experience.

We still haven't managed to make something as simple as  styleable. Something like a date picker is *far* more
complex to style.

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

Re: Merge moved to Thursday 29th

[nhirata]

1) The reason why we've merge in the beginning of the week is traditionally 
there has been fall outs as well as chemspills.  ie this helps reduce the 
number of people that have to work weekends in order to fix up the branches.  
In case you need evidence of the fall outs, you can see the crash rates usually 
increase right after a merge.

2) There was an assumption that b2g would also move at this time and has moved 
master 2.6 prematurely; we still have not finished the project.  As far as I 
know, taskcluster is not setup to make 2.5 builds.  With the possibility of 
pvtbuild server going away,in the near future, this causes an issue to the B2G 
project.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Carlos Valim Coragem]

Hi Jonas!

 Thanks for your response :)

> On Fri, Oct 30, 2015 at 12:36 AM, Xidorn Quan 
> wrote:
>> Authors sometimes just want something usable. It doesn't matter if it
>> is not stylable, or it doesn't fit in the UI. When they really need to
>> start caring about such things, they can switch to use jQuery UI then.
>
> I think this is true for a *very* small number of authors. Small
> enough that we should spend our time on more impactful things.


 I do not think implement these things is a waste of time, however, we
need to care about semantics too, it's much present in HTML5. I think do
not invest a little time to implement these semantic attributes is bad
for Firefox, it causes people to be thinking that Firefox has fallen
behind compared to other browsers. This is my humble opinion.


>
> Look at the tooling websites that we use within mozilla. bugzilla.m.o,
> treeherder.m.o, wiki.m.o and MDN all care about a pleasant look and
> feel.
>
> Also remember that jQuery UI also works fine for websites that "just
> wants something usable".


 If we can use these controls directly in the HTML, why shouldn't we use
them?


>
> / Jonas
>

Keep on rockin'!
Coragem

-- 
Carlos A C Valim [@_Coragem]
www.coragem.info
Eu sou um membro da FSF - Ajude-nos a apoiar o software livre!
http://my.fsf.org/register_form?referrer=9618
LPIC-1 #LPI ID LPI000205754
http://lpi.org

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

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

[Carlos Valim Coragem]

Hi Xidorn!

 Thanks for your response :)

> On Fri, Oct 30, 2015 at 10:25 AM, Ehsan Akhgari 
>>
>> Your experience is expected.  We have an implementation of these form
>> controls on Android, but not on desktop.  We have been waiting for UX
>> specs
>> for this feature on desktop, as you have discovered.  :-)
>
> We really should push UX people to have that done. It is a pain that
> those things are not usable. Having those input types will save plenty
> of time for frontend developers to make their apps support Firefox.
> (Otherwise, they might just drop the Firefox support.)
>
> - Xidorn
>

 Good point! I also think it's very important to implement these
attributes in Firefox, these attributes are in the HTML5 specs, so why
not implement them? Knowing that browsers like Chrome, Opera and IE are
supporting these attributes, I think Firefox has fallen behind in some
way.

Keep on rockin'!
Coragem

-- 
Carlos A C Valim [@_Coragem]
www.coragem.info
Eu sou um membro da FSF - Ajude-nos a apoiar o software livre!
http://my.fsf.org/register_form?referrer=9618
LPIC-1 #LPI ID LPI000205754
http://lpi.org

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

Re: Collecting web platform features implementation status

[Andrew Overholt]

Harald (on CC) is working on it here:

https://github.com/mozilla/platatus
On Oct 29, 2015 6:38 PM, "Tom Schuster"  wrote:

> 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 
> wrote:
> >
> >> On 16/07/15 21:26, Anthony Ricaud wrote:
> >>
> >>> Potch and I are working on a website to present Mozilla's point of view
> >>> on various web platform features. Other browsers have similar websites
> >>> [1] [2] [3]. This project has been in lingo for a while so, to get it
> >>> out the door, we're going to focus on one information: what is
> Mozilla's
> >>> opinion on features that have not been shipped yet. We see 4 possible
> >>> answers: in development, favorable, not favorable, no opinion.
> >>>
> >>> In order to get accurate data and update it regularly, we need your
> >>> help. Please go to the following etherpad and insert any information
> >>> that can help us:
> >>> https://etherpad.mozilla.org/gecko-web-platform-dashboard
> >>>
> >>> Thanks for your help!
> >>>
> >>> [1] https://www.chromestatus.com/features
> >>> [2] https://status.modern.ie
> >>> [3] http://www.webkit.org/status.html
> >>>
> >> Reminder: We need your help! Please submit a pull request against
> >> https://github.com/Rik/platform-status/blob/master/features.json.
> >>
> >> (I've only received one pull request since moving this JSON to Github
> :( )
> >>
> >> ___
> >> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding out if the main thread is currently animating

[David Rajchenbach-Teller]

I have posted an early patch on bug 1219145 that approximates
"animating" to "is anyone listening for vsync". If anybody knowledgeable
could take a look, I'd be grateful.

Cheers,
 David

On 30/10/15 02:33, Karl Tomlinson wrote:
> 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 lasts more than 32ms".
>>
>> Do we have a reliable way to do that?
> 
> I would guess that our main thread animations all run off a single
> 60 Hz throttle, which I assume is the RefreshDriver.  If that
> throttle has no jobs scheduled to run, then I expect there are no
> animations in progress.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding out if the main thread is currently animating

[Honza Bambas]

On 10/30/2015 2:35, Ehsan Akhgari wrote:

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 to measure input latency? Based 
on event timestamps?


The reason I'm asking is that with e10s, I sometimes see long (even 
multi-second!) delays between for example clicking the new tab button, 
or for the title of a new tab to appear after the tab being initially 
painted) that are very visible to the user, and can't be detected that 
way.  I think it would be nice to come up with a set of user actions 
in the primary UI and manually measure their delay based on the 
knowledge that we have about the asynchronous nature of their 
implementation.




This is exactly what I want Backtrack for 
(http://www.janbambas.cz/new-gecko-performance-tool-backtrack/). That 
tool will allow you to define "goal markers" instrumentation in the code 
that you get a list of and can track back to the original user 
interaction event and see where all you are blocked by what, across 
processes/threads/timers etc and isolate the blocking activity on "your 
goal path".  Like a long async callback, but with added profiler data by 
side.


I don't work on it right now as I'm occupied with NSec unfortunately...

-hb-


Cheers,
Ehsan
___
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: WebVR

[Gervase Markham]

On 29/10/15 17:07, vladi...@mozilla.com wrote:
>> At one point, integrating with available hardware required us to use
>> proprietary code. Is shipping proprietary code in Firefox any part of
>> this plan, or not?
> 
> No.

Awesome! :-)

Gerv


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

Re: Finding out if the main thread is currently animating

[David Rajchenbach-Teller]

This sounds like a good idea. I'll see if I can get some time budgeted
to help with this during Q1.

Cheers,
 David

On 30/10/15 15:09, Honza Bambas wrote:

> This is exactly what I want Backtrack for
> (http://www.janbambas.cz/new-gecko-performance-tool-backtrack/). That
> tool will allow you to define "goal markers" instrumentation in the code
> that you get a list of and can track back to the original user
> interaction event and see where all you are blocked by what, across
> processes/threads/timers etc and isolate the blocking activity on "your
> goal path".  Like a long async callback, but with added profiler data by
> side.
> 
> I don't work on it right now as I'm occupied with NSec unfortunately...
> 
> -hb-
> 
>> Cheers,
>> Ehsan
>> ___
>> 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


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform