Re: Avoiding jank in async functions/promises?

2017-05-17 Thread Kan-Ru Chen 
On Thu, May 18, 2017, at 10:10 AM, L. David Baron wrote:
> On Thursday 2017-05-18 11:22 +1000, Mark Hammond wrote:
> > I'm wondering if there are any ideas about how to solve this optimally?
> > Naively, it seems that the (broadest sense of the term) "platform" might be
> > able to help here using it's knowledge of the event-loop state - eg, a
> > function that indicates "are we about to starve the event loop and become
> > janky?", or possibly even the whole hog (ie, "please yield to the event loop
> > if you think now is a good time, otherwise just hand back a pre-resolved
> > promise").
> 
> One other option would be to use time rather than iterations as a
> measure of when to return.
> 
> A platform API that's somewhat like this is requestIdleCallback,
> whose spec is at https://w3c.github.io/requestidlecallback/ -- in
> particular, the timeRemaining() method on the IdleDeadline object
> passed to the callback.  See also:
> https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
> https://developer.mozilla.org/en-US/docs/Web/API/Background_Tasks_API
> 
> I'm not sure whether it works for privileged (chrome) JS, but it
> seems like it ought to...

The non-DOM version of rIC is being tracked by
https://bugzilla.mozilla.org/show_bug.cgi?id=1353206 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1358476

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

Re: Intent to ship: SourceMap header

2017-05-17 Thread Anne van Kesteren 
On Wed, May 17, 2017 at 8:14 PM, Nick Fitzgerald
 wrote:
> At the time of the thread, I had hopes that the source map RFC repo would
> take off. It never did. Maybe making a "proper" WHATWG standard would help
> get people involved, in which case it would be a good idea. I wasn't trying
> to push back in that thread, just making sure that we had good answers to
> those questions because if we didn't then why do it in the first place.

Perhaps https://console.spec.whatwg.org/ is a good fit? Although that
mostly deals with web-exposed behavior at this point.


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

Re: Avoiding jank in async functions/promises?

2017-05-17 Thread Mark Hammond 

On 5/18/17 12:03 PM, Boris Zbarsky wrote:

On 5/17/17 9:22 PM, Mark Hammond wrote:

I'm wondering if there are any ideas about how to solve this optimally?


I assume 
https://w3c.github.io/requestidlecallback/#the-requestidlecallback-method doesn't 
have quite the right semantics here?  That would let you run when the 
browser is idle, and give you some idea of how long you can run for 
before you should yield.


The only way I could see that work would be if the code was explicitly 
written as a consumer of a queue of promises (along the lines of that 
"Cooperative Scheduling of Background Tasks API" example). However, I 
can't see how code written "naturally" (eg, that loop in PlacesUtils.jsm 
I linked to) could leverage that.


IdleDeadline.timeRemaining() does appear to have the semantics I want, 
but just seems "inverted" in terms of how it is used. A function that, 
basically, returns this value synchronously sounds like what I am after 
though.


Thanks,

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

Re: Avoiding jank in async functions/promises?

2017-05-17 Thread Ben Kelly 
On Wed, May 17, 2017 at 10:19 PM, Ben Kelly  wrote:

> FWIW, we have a similar problem in the native TimeoutManager::RunTImeout()
> method.  I'm using a time budget approach to make it adapt to different
> hardware better.
>

I meant to include the bug number here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1343912
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Avoiding jank in async functions/promises?

2017-05-17 Thread Ben Kelly 
On Wed, May 17, 2017 at 10:03 PM, Boris Zbarsky  wrote:

> On 5/17/17 9:22 PM, Mark Hammond wrote:
>
>> I'm wondering if there are any ideas about how to solve this optimally?
>>
>
> I assume https://w3c.github.io/requestidlecallback/#the-requestidleca
> llback-method doesn't have quite the right semantics here?  That would
> let you run when the browser is idle, and give you some idea of how long
> you can run for before you should yield.
>

If rIC is not the right semantics, we could also set a time budget instead
of a magic flat limit.  Every N operations call performance.now() and check
to see if the configured time exceeds the limit.

FWIW, we have a similar problem in the native TimeoutManager::RunTImeout()
method.  I'm using a time budget approach to make it adapt to different
hardware better.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Avoiding jank in async functions/promises?

2017-05-17 Thread L. David Baron 
On Thursday 2017-05-18 11:22 +1000, Mark Hammond wrote:
> I'm wondering if there are any ideas about how to solve this optimally?
> Naively, it seems that the (broadest sense of the term) "platform" might be
> able to help here using it's knowledge of the event-loop state - eg, a
> function that indicates "are we about to starve the event loop and become
> janky?", or possibly even the whole hog (ie, "please yield to the event loop
> if you think now is a good time, otherwise just hand back a pre-resolved
> promise").

One other option would be to use time rather than iterations as a
measure of when to return.

A platform API that's somewhat like this is requestIdleCallback,
whose spec is at https://w3c.github.io/requestidlecallback/ -- in
particular, the timeRemaining() method on the IdleDeadline object
passed to the callback.  See also:
https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
https://developer.mozilla.org/en-US/docs/Web/API/Background_Tasks_API

I'm not sure whether it works for privileged (chrome) JS, but it
seems like it ought to...

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Re: Avoiding jank in async functions/promises?

2017-05-17 Thread Boris Zbarsky 

On 5/17/17 9:22 PM, Mark Hammond wrote:

I'm wondering if there are any ideas about how to solve this optimally?


I assume 
https://w3c.github.io/requestidlecallback/#the-requestidlecallback-method 
doesn't have quite the right semantics here?  That would let you run 
when the browser is idle, and give you some idea of how long you can run 
for before you should yield.


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

Avoiding jank in async functions/promises?

2017-05-17 Thread Mark Hammond 

Given our recent performance push, I thought I'd bring this topic up again.

When writing loops using async functions in browser code, it's still 
very easy to cause jank. For example, a trivial function:


> async function janky() {
>   for (let i = 0; i < 10; i++) {
> await Promise.resolve();
>   }
> }
>
> janky().then(() => console.log("done"));

will cause the browser to hang. While that's not considered a bug in the 
implementation of the promise scheduler, and might not be particularly 
surprising in that trivial example, lots of real-world code can still 
hit this case - which both isn't obvious from casual inspection, and 
even if it was, doesn't have an obvious solution.


Concretely, we struck this a couple of years ago in bug 1186714 - 
creating a backup of all bookmarks ends up looking alot like the loop 
above. In addition, the Sync team is moving away from nested event loops 
towards promises, and our work to date is hitting this problem.


In bug 1186714, we solved the problem by inserting code into the loop 
that looks like:


>if (i % 50 == 0) {
>  await new Promise(resolve => {
>Services.tm.dispatchToMainThread(resolve);
>  });
>}

http://searchfox.org/mozilla-central/rev/f55349994fdac101d121b11dac769f3f17fbec4b/toolkit/components/places/PlacesUtils.jsm#2022

so we explicitly yield to the event loop every 50 iterations. However, 
this isn't optimal as the 50 is obviously a magic number, determined by 
experimentation on a couple of machines - when running on low spec 
hardware, this loop is almost certainly still janky. If we try and err 
on the side of caution (eg, yielding every iteration) we see the wall 
time of the loop take a massive hit (around twice as long in that bug).


I'm wondering if there are any ideas about how to solve this optimally? 
Naively, it seems that the (broadest sense of the term) "platform" might 
be able to help here using it's knowledge of the event-loop state - eg, 
a function that indicates "are we about to starve the event loop and 
become janky?", or possibly even the whole hog (ie, "please yield to the 
event loop if you think now is a good time, otherwise just hand back a 
pre-resolved promise").


Or maybe there are simpler options I've overlooked?

Thanks,

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

Intent to remove: Insecure use of Encrypted Media Extensions

2017-05-17 Thread Chris Pearce 
Summary: The EME spec [1] states that EME should only be usable from a secure 
origin (i.e. on a domain being served over HTTPS). Currently Gecko's 
implementation works on insecure origins (i.e. sites served over unencrypted 
HTTP). To bring our implementation in line with the spec, we're going to remove 
support for EME on non-secure origins.

Sites using EME that are not using secure origins should switch to HTTPS as 
soon as possible.

Chrome has just removed support for insecure EME in Chrome 58, their most 
recent release.

Motivation: EME makes use of proprietary CDMs that have access to persistent 
storage and that may transmit identifiers to DRM license servers. Requiring 
secure origin and transport makes it harder for the CDM to be attacked by 
others on the channel.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1322517

Standard: https://www.w3.org/TR/encrypted-media/

Platform coverage: This will affect everywhere that we support EME; Windows, 
MacOS, Linux, Android.

Estimated target date: TBD. Hopefully we can ship this by the end of 2017.

Our telemetry [2] indicates that about 18% of EME use is still on insecure 
origins. We're shipping a deprecation warning in the WebConsole in Firefox 55, 
and given that Chrome have removed this in their latest release I expect we 
should see migration of sites using EME to HTTPS. Once our telemetry indicates 
that use of EME on insecure origins is sufficiently rare, we will go ahead and 
remove support for EME on insecure origins.


[1] https://www.w3.org/TR/encrypted-media/#privacy-secureorigin
[2] https://mzl.la/2rs9maH
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

2017-05-17 Thread Nick Fitzgerald 
On Wed, May 17, 2017 at 10:51 AM, Tom Tromey  wrote:

> > "Boris" == Boris Zbarsky  writes:
>
> >> https://github.com/source-map/source-map-rfc
>
> Boris> Are there any plans to have a standard here?
>
> All I found was this:
> https://groups.google.com/forum/#!topic/mozilla.dev.js-
> sourcemap/SD8sZ_7VFpw
>
> ... my reading of that was that there wasn't interest on our part at the
> time.  I suppose we could reopen that.
>

​At the time of the thread, I had hopes that the source map RFC repo would
take off. It never did. Maybe making a "proper"​ WHATWG standard would help
get people involved, in which case it would be a good idea. I wasn't trying
to push back in that thread, just making sure that we had good answers to
those questions because if we didn't then why do it in the first place.

In my experience, trying to get anyone to comment or provide feedback on
source map RFCs was a huge pain, and it felt to me like nobody (other
browser devtools teams, maintainers of compilers targeting JS) cared enough
about source maps to get involved or contribute.

If the effort re-materializes, here's what I think should be focused on:

* Clean up the spec text and any ambiguities it may have; make it a
"proper" standard
* Pull a wasm on the source map format: create an isomorphic, but much more
compact binary format
* Add the ability to encode source level scopes, bindings, and a way to
recover bindings' values
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

2017-05-17 Thread Tom Tromey 
> "Boris" == Boris Zbarsky  writes:

>> https://github.com/source-map/source-map-rfc

Boris> Are there any plans to have a standard here?

All I found was this:
https://groups.google.com/forum/#!topic/mozilla.dev.js-sourcemap/SD8sZ_7VFpw

... my reading of that was that there wasn't interest on our part at the
time.  I suppose we could reopen that.

Boris> It really would be good
Boris> to have all UAs converge on a single format here, both for the header
Boris> and for the sourcemap itself, especially if we're going to have an
Boris> unprefixed name for the header...  Speaking of which, is there a plan
Boris> to register this header with IANA (see
Boris> )?

I believe there is a single format for the header and the sourcemap
itself; it's just that the spec is that Google doc and the way to change
the spec is to submit a PR against the (very quiet) RFC repo on github.

I'm not aware of anybody registering the header with the IANA.  However
I've only been working in this area for a few weeks.

Boris> Is there any web-page-observable behavior change from sourcemaps
Boris> (e.g. .stack on exceptions?), or is it all about how devtools behave?

It's only observable using devtools.

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

Re: Intent to ship: SourceMap header

2017-05-17 Thread Nick Fitzgerald 
Error().stack is not affected by source maps (nor should it be IMO). This
is just devtools facing with nothing that is web observable.

On Wed, May 17, 2017 at 9:06 AM, Boris Zbarsky  wrote:

> On 5/17/17 11:01 AM, Tom Tromey wrote:
>
>> In this case I think this does not apply, because as far as I'm aware
>> source maps are not part of any standard process; rather there is:
>>
>> https://github.com/source-map/source-map-rfc
>>
>
> Are there any plans to have a standard here?  It really would be good to
> have all UAs converge on a single format here, both for the header and for
> the sourcemap itself, especially if we're going to have an unprefixed name
> for the header...  Speaking of which, is there a plan to register this
> header with IANA (see )?
>
> Is there any web-page-observable behavior change from sourcemaps (e.g.
> .stack on exceptions?), or is it all about how devtools behave?
>
> -Boris
>
> ___
> 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: SourceMap header

2017-05-17 Thread Boris Zbarsky 

On 5/17/17 11:01 AM, Tom Tromey wrote:

In this case I think this does not apply, because as far as I'm aware
source maps are not part of any standard process; rather there is:

https://github.com/source-map/source-map-rfc


Are there any plans to have a standard here?  It really would be good to 
have all UAs converge on a single format here, both for the header and 
for the sourcemap itself, especially if we're going to have an 
unprefixed name for the header...  Speaking of which, is there a plan to 
register this header with IANA (see 
)?


Is there any web-page-observable behavior change from sourcemaps (e.g. 
.stack on exceptions?), or is it all about how devtools behave?


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

Re: Removing "MathML View Source" menu item? [was: Can we remove nsIEntityConverter?]

2017-05-17 Thread J. Ryan Stinnett 
As an occasional contributor to view source, I think it would be nice to
remove the MathML support from m-c like you are proposing, as it definitely
increased the maintenance burden when we reworked view source into a tab a
while ago, and my assumption is the usage of MathML view source is
relatively low (though I currently have no data to back that up).

Looking at the add-on, it seems to miss one feature: Currently in m-c, you
can select a portion of a MathML expression, choose "View Selection
Source", and see the MathML source for the selection. If that's added to
your add-on, I believe you'd have feature parity with the existing MathML
view source support.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1365626 to remove
MathML view source from m-c.

- Ryan

On Sat, May 6, 2017 at 5:40 AM, Frédéric Wang  wrote:

> Le 30/04/2016 à 12:25, Henri Sivonen a écrit :
> > We ship data tables for converting from Unicode to HTML entities.
> > These tables obviously take space. (They are not optimized for space
> > usage, either.) As far as I can tell, these tables are not used at all
> > in Fennec. In desktop Firefox, these data tables are used only for the
> > MathML View Source feature.
> >
> > Additionally, a subset of the tables is used by some XPCOM-based
> > extensions, but those extensions seem to be obsolete or abandoned or
> > don't seem to be using the feature for a very good reason.
> >
> > These data tables are not exposed to the Web Platform.
> >
> > In https://bugzilla.mozilla.org/show_bug.cgi?id=1048191 I proposed
> > removing this for mobile only, but how about we just remove this
> > altogether in order to make both Fennec and desktop Firefox smaller?
> >
>
> Hi,
>
> I'm resurrecting this old thread, just to say that there is now a
> WebExtension implementing the "MathML view source" feature (using better
> syntax highlighting and handling the invisible spaces too):
>
> https://addons.mozilla.org/en-US/firefox/addon/mathml-view-source/
>
> So I'm proposing to remove that feature from the core mozilla source.
> The only concern I have is for Thunderbird/Seamonkey as it is not
> clear yet what will be the future regarding WebExtensions.
>
> Any opinions?
>
> --
> Frédéric Wang
> ___
> 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

Intent to ship: SourceMap header

2017-05-17 Thread Tom Tromey 
I intend to turn support for the SourceMap response header on by default
in nightly, and let it ride the trains.  It has not been developed
behind a preference.  The existing X-SourceMap header will still be used
if SourceMap is not seen; this matches the behavior of Chrome and
WebKit.

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1346936

Link to standard: 
https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#

Testing: As far as I know there are no web-platform-tests; but we do
have mochitests for the feature.


The intent-to-ship guidelines say:

An Intent to Ship requires either a web platform test suite or such
issues to be filed explaining why such a test suite is currently
impossible or in the progress of being upstreamed.

In this case I think this does not apply, because as far as I'm aware
source maps are not part of any standard process; rather there is:

https://github.com/source-map/source-map-rfc

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

Re: Nightly updates disabled in light of 1364878

2017-05-17 Thread Nick Thomas 
Updates have been re-enabled for Nightly.

On 17 May 2017 at 07:00, Mihai Tabara  wrote:

> Updates to nightly are yet again available, pointing to last good
> build we know and agreed on channel meeting, which is the Sunday one
> (20170514).
> Thanks.
>
> On Mon, May 15, 2017 at 3:02 PM, Mihai Tabara  wrote:
> > We've disabled updates in light of events occurring in bug 1364878.
> > We can ultimately point users to last good build but until we decide
> > so, updates are better off.
> ___
> release-drivers mailing list
> release-driv...@mozilla.org
> https://mail.mozilla.org/listinfo/release-drivers
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Introducing Nightly soft code freeze

2017-05-17 Thread Ritu Kothari 
+dev-platform (correct mailing list this time)

On Tue, May 16, 2017 at 4:15 PM, Ritu Kothari  wrote:

> Goal: We need to implement a soft code freeze on mozilla-central repo
> during the last week of Nightly cycle.
>
> Nightly version
>
> Soft code freeze
>
> Merge day
>
> 55
>
> June 5th - June 12th
>
> June 12th
>
> 56
>
> July 31st - Aug 7th
>
> Aug 7th
>
> 57
>
> Sept 18th - Sept 25th
>
> Sept 25th
>
> Why?
>
> In the post-dawn world (aka no aurora stabilization), we need a mechanism
> to limit the risk to quality with last-minute changes landing in Nightly
> before Merge day.
>
> How?
>
> The week before Merge day will involve increased scrutiny of patches
> landing in mozilla-central that might regress quality and/or stability.
> This code freeze does not mean mozilla-central repo will be locked and no
> patches will be allowed to land. However, developers are strongly urged not
> to land any fixes that are deemed risky or enable (pref-controlled)
> features a week before Merge day. We recommend you wait until after Merge
> day to land such fixes on mozilla-central.
>
> We will be more aggressive with backing out patches from m-c that cause
> new regressions and merge blockers. If a patch is blamed to introduce a new
> regression/top crasher in Nightly, instead of waiting for a followup fix
> which we normally do, release mgmt team will ask for an immediate backout.
>
> What?
>
> Dos and Don’ts during the soft code freeze:
>
> Do:
>
>-
>
>Be ready to backout patches that cause crash spikes, new crashes,
>severe regressions
>-
>
>Monitor new regressions and escalate merge blockers
>-
>
>Support release management to prioritize fixing merge blockers
>
> Do Not:
>
>-
>
>Land a risky patch or a large patch a week before Merge day
>-
>
>Land new features a week before Merge day
>-
>
>Flip prefs that enable new Features that were untested in Nightly cycle
>-
>
>Plan to kick off new experiments
>
> Please let us know if you have any questions/concerns.
>
> Thanks,
> Release management team
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Nightly updates disabled in light of 1364878

2017-05-17 Thread Mihai Tabara 
Updates to nightly are yet again available, pointing to last good
build we know and agreed on channel meeting, which is the Sunday one
(20170514).
Thanks.

On Mon, May 15, 2017 at 3:02 PM, Mihai Tabara  wrote:
> We've disabled updates in light of events occurring in bug 1364878.
> We can ultimately point users to last good build but until we decide
> so, updates are better off.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Volunteer maintainer wanted: mac x86

2017-05-17 Thread Nicholas Nethercote 
https://developer.mozilla.org/en/docs/Supported_build_configurations still
lists x86/Mac as a tier 1 platform.

Should it be moved to tier 3, or removed altogether?

Nick

On Thu, Dec 1, 2016 at 2:29 AM, Benjamin Smedberg 
wrote:

> As of Firefox 53, we are intending to switch Firefox on mac from a
> universal x86/x86-64 build to a single-architecture x86-64 build.
>
> To simplify the build system and enable other optimizations, we are
> planning on removing support for universal mac build from the Mozilla build
> system.
>
> The Mozilla build and test infrastructure will only be testing the x86-64
> codepaths on mac. However, we are willing to keep the x86 build
> configuration supported as a community-supported (tier 3) build
> configuration, if there is somebody willing to step forward and volunteer
> as the maintainer for the port. The maintainer's responsibility is to
> periodically build the tree and make sure it continues to run.
>
> Please contact me directly (not on the list) if you are interested in
> volunteering. If I do not hear from a volunteer by 23-December, the Mozilla
> project will consider the Mac-x86 build officially unmaintained.
>
> --BDS
> ___
> 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