Re: We need better canaries for JS code

[David Teller]

This should be feasible.

Opening bug 1409852 for the low-level support.

On 18/10/17 22:22, Dan Mosedale wrote:
> Could we do this on a per-module opt-in basis to allow for gradual
> migration?  That is to say, assuming there's enough information in the
> stack to tell where it was thrown from (I'm guessing that's the case
> most of the time), by default, ignore these errors unless they're from
> code in an opted-in module?
> 
> Dan
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We need better canaries for JS code

[Kris Maglione]

On Wed, Oct 18, 2017 at 07:22:09PM -0700, Daniel Veditz wrote:

On Wed, Oct 18, 2017 at 4:51 AM, Mark Banner  wrote:


I did an experiment, and the only way I got an error out was to have
"javascript.options.strict" on and



Why isn't it a code-style/review requirement that our own internal JS
include "use strict"? As a quick check I found 659 .jsm files in our tree
and only about 500 with "use strict". A quick skim of .js files shows a
similar ratio. It's not terrible (call it a "B" grade?) but we could do
better.


It is, in some areas, depending on their ESLint rules:

http://searchfox.org/mozilla-central/search?q=%22strict%22=true=false=eslint

And it's automatically enforced everywhere in JSM and JS component code. 
To date, we've mostly avoided enforcing it for browser window code to 
avoid breaking extensions that used arguments.callee.caller (despite my 
endorsement for breaking those extensions...), but that's not really an 
issue anymore, so we should probably move towards enforcing it for all 
chrome JS.

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

Re: We need better canaries for JS code

[Daniel Veditz]

On Wed, Oct 18, 2017 at 4:51 AM, Mark Banner  wrote:

> I did an experiment, and the only way I got an error out was to have
> "javascript.options.strict" on and
>

​Why isn't it a code-style/review requirement that our own internal JS
include "use strict"? As a quick check I found 659 .jsm files in our tree
and only about 500 with "use strict"​. A quick skim of .js files shows a
similar ratio. It's not terrible (call it a "B" grade?) but we could do
better.

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

Re: Canonical cinnabar repository

[Myk Melez]

Myk Melez 
2017 September 26 at 17:40

Kartikaya Gupta 
2017 September 26 at 08:49
So from the discussion here it sounds like using a full (i.e.
non-grafted) cinnabar repository "just works" for most people. It has
the problem of missing CVS history but it seems like people who need
that often can use searchfox and/or a gecko-dev branch in a cinnabar
repo to get it.
Yes, and can we also integrate CVS history into a full cinnabar 
repository like mozilla/gecko using Git's "replace" command.
I've now done this for mozilla/gecko, so if you clone/fetch that repo, 
then you'll get both a "central" branch and a "cvs" branch.


The "central" branch contains mozilla-central history, and I continue to 
sync it with upstream mozilla-central using cinnabar. The "cvs" branch 
contains the CVS history.


To integrate them (without modifying either history), fetch replacement 
refs:


git fetch origin 'refs/replace/*:refs/replace/*'

(Replace "origin" with the name of your mozilla/gecko remote, if it 
differs.)


Then common Git commands (diff, log, bisect, etc.) will behave as if the 
oldest commit in "central" (e18f9a3) is the newest commit in "cvs" 
(3ec464b), and you can use them to traverse the entire history of Gecko 
transparently.


I've also updated https://wiki.mozilla.org/GitHub/Gecko_Repositories to 
include this information.


-myk

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

Re: Change in the way e10s and multi are enabled on Nightly

[Andrew Swan]

On Wed, Oct 18, 2017 at 3:22 PM, Justin Dolske  wrote:

> On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan  wrote:
>
>>
>> One more thing to point out: with the removal of e10srollout, I also
>> removed the code that would disable e10s if we detected a
>> non-multiprocessComptaible extension. We are entirely relying on the addon
>> manager to refuse to install such extensions.
>>
>>
> If someone on a pre-release channel enables legacy addons, will that still
> refuse to load non-E10S compatible addons? (I hope so?)
>

Legacy extensions can only be enabled on nightly and unbranded builds (not
on beta).  On Nightly, a non-MPC extension won't load unless you also flip
the preference extensions.allow-non-mpc-extensions.  If both those prefs
are flipped on Nightly, we will load the extension with shims enabled but
will not disable e10s.

Why don't we rip this all out you ask?  We're still using shims in
automation, see bug 1351512.  If anybody reading this has some spare cycles
(ha) and wants to do a good deed, you should be able to find remaining uses
by running tests with extensions.interposition.enabled set to false and
tracing resulting failures...

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

Re: Change in the way e10s and multi are enabled on Nightly

[Justin Dolske]

On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan  wrote:

>
> One more thing to point out: with the removal of e10srollout, I also
> removed the code that would disable e10s if we detected a
> non-multiprocessComptaible extension. We are entirely relying on the addon
> manager to refuse to install such extensions.
>
>
If someone on a pre-release channel enables legacy addons, will that still
refuse to load non-E10S compatible addons? (I hope so?)

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

Re: We need better canaries for JS code

[Dave Townsend]

I'm wary when it comes to code that lives in tree as it's both an added
thing for contributors to learn and an added build step for that code. Also
by doing it only within a module you end up missing out on a bunch of
benefits. For system add-ons that live elsewhere though I think that is up
to the developers of that add-on to decide what they want to do bearing in
mind they'll be adding a build step as part of getting their code into m-c.

On Wed, Oct 18, 2017 at 2:21 PM Dan Mosedale  wrote:

> Dave, how would you feel about deciding on one of those and allowing
> modules to opt-in to using them, perhaps just as an experiment.  Presumably
> most existing modules wouldn't, but new ones being written might.
>
> Dan
> 2017-10-18 9:06 GMT-07:00 Dave Townsend :
>
>> On Wed, Oct 18, 2017 at 4:51 AM Mark Banner  wrote:
>>
>>> I remember that we had bugs of this kind lurking for years in our
>>> codebase, in code that was triggered daily and that everybody believed
>>> to be tested.
>>>
>>> I'd like to think that there is a better way to handle these bugs,
>>> without waiting for them to explode in our user's face. Opening this
>>> thread to see if we can find a way to somehow "solve" these bugs, either
>>> by making them impossible, or by making them much easier to solve.
>>>
>>> ESLint has caught some bugs - mainly undefined and unused related
>>> issues, and is spread through most of the production javascript code.
>>> Unfortunately it isn't able to catch this class of error. For that, we'd
>>> need something like Flow. Last time I looked at it, it didn't feel like a
>>> good fit for us, although I didn't go too deep, and I think there may have
>>> been other people that were looking at it.
>>>
>>
>> As a datapoint, I've looked at both Flow and TypeScript. Both are good
>> tools that work well if you're writing code from scratch with them but for
>> existing code they flag many many pre-existing problems, the vast majority
>> of which aren't really problems just cases where the tools can't infer what
>> is going on without adding type info to the script. I came to the
>> conclusion that it would be too much work to use either in our main
>> codebase.
>>
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We need better canaries for JS code

[Boris Zbarsky]

On 10/18/17 2:37 PM, Steve Fink wrote:
Is there any way to detect if a finalized Promise swallowed an exception 
without "handling" it in some way or other, even if very heuristically?


We used to have such a way.  It requires doing things during 
finalization, which is not great.


But we can also just do the normal promise detection: a last promise in 
a chain that gets rejected and no one does a catch() before we go to the 
event loop.  We already have that infrastructure in place...


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

Change in the way e10s and multi are enabled on Nightly

[Blake Kaplan]

Hello everybody,

I'm in the process of landing a change in bug 1406212 [1] that changes the
way that we handle enabling or disabling of e10s and e10s-multi. This
change will ride the trains, so Firefox 58 will be the first version with
the simplified logic.

To recap the current situation: we have 4 prefs that control these
features: browser.tabs.remote.autostart, browser.tabs.remote.autostart.2,
dom.ipc.processCount, and dom.ipc.processCount.web. On Nightly,
browser.tabs.remote.autostart.2 defaults to true and dom.ipc.processCount
defaults to 4. On Beta and Release, they default to false and 1
respectively. We then update these preferences via the e10srollout addon.
This has been the cause of much confusion and several bugs.

As of today (assuming the patch sticks), these features will be controlled
by the prefs browser.tabs.remote.autostart and dom.ipc.processCount. They
default to true and 4, respectively and behave as one would expect.

One more thing to point out: with the removal of e10srollout, I also
removed the code that would disable e10s if we detected a
non-multiprocessComptaible extension. We are entirely relying on the addon
manager to refuse to install such extensions.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1406212
-- 
Blake
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We need better canaries for JS code

[Ryan VanderMeulen]

Note that we also have bug 920191 on file for making JS exceptions fatal in
the harness. One of the big blockers to that has always been cleaning up
the existing set of problems, but maybe it would be helpful for some of
these issues if/when we could drive that into happening.

-Ryan


On Wed, Oct 18, 2017 at 12:20 PM, J. Ryan Stinnett  wrote:

> This may not be what you want here, but just so you are aware of the
> option...
>
> You can use `Services.console.registerListener`[1] in a test harness,
> etc. to hear messages logged to the console. The harness could count
> messages of a certain type (like script errors) and fail the test if
> there's an unexpected count (similar to assertion handling in some
> harnesses).
>
> Some test harnesses already register console listeners, but many of them
> just echo the messages to the test log without examining them further.
>
> For JS errors logged to the console, you can QI them to nsIScriptError and
> examine more details like line, column, stack, etc.
>
> Anyway, might not cover all the cases envisioned here, but it's one tool
> available to us.
>
> [1]: http://searchfox.org/mozilla-central/search?q=console.
> registerListener=true=false=
>
> - Ryan
>
> On Wed, Oct 18, 2017 at 6:51 AM, Mark Banner  wrote:
>
>> Looping in firefox-dev as well, as I thin this is an important discussion.
>>
>> On 18/10/2017 09:28, David Teller wrote:
>>
>> Hi everyone,
>>
>>   Yesterday, Nightly was broken on Linux and MacOS because of a typo in
>> JS code [1]. If I understand correctly, this triggered the usual
>> "undefined is not a function", which was
>>
>> 1/ uncaught during testing, as these things often are;
>>
>> Part of the reason it was uncaught, is that there's no automated test
>> coverage for that bit of code. It is a migration from one version to the
>> other, but unless there is an explicit test (and I don't see one) that line
>> won't be hit.
>>
>> This seems to be a common theme with various migration routes in the code
>> base, when I've asked about ensuring more automated testing there before I
>> feel like I've got shrugs.
>>
>> Admittedly, a lot of it is simple code, and should be correct, but as
>> we've seen, mistakes can be made. Should we now be changing our policy?
>>
>> At a minimum, I wonder if we could write some sort of simple test for
>> CustomizableUI that would go through most routes (with minimal updates for
>> each change).
>>
>> 2/ basically impossible to diagnose in the wild, because there was no
>> error message of any kind.
>>
>> I did an experiment, and the only way I got an error out was to have
>> "javascript.options.strict" on and "browser.dom.window.dump.enabled".
>> Unfortunately the breakage was such that the browser console couldn't be
>> opened, so you'd just having strict on wasn't enough.
>>
>> I remember that we had bugs of this kind lurking for years in our
>> codebase, in code that was triggered daily and that everybody believed
>> to be tested.
>>
>> I'd like to think that there is a better way to handle these bugs,
>> without waiting for them to explode in our user's face. Opening this
>> thread to see if we can find a way to somehow "solve" these bugs, either
>> by making them impossible, or by making them much easier to solve.
>>
>> ESLint has caught some bugs - mainly undefined and unused related issues,
>> and is spread through most of the production javascript code. Unfortunately
>> it isn't able to catch this class of error. For that, we'd need something
>> like Flow. Last time I looked at it, it didn't feel like a good fit for us,
>> although I didn't go too deep, and I think there may have been other people
>> that were looking at it.
>>
>> I have one proposal. Could we change the behavior of the JS VM as follows?
>>
>> - The changes affect only Nightly.
>> - The changes affect only mozilla chrome code (including system add-ons
>> but not user add-ons or test code).
>> - Any programmer error (e.g. SyntaxError) causes a crash a crash that
>> displays (and attaches to the CrashReporter) both the JS stack in and
>> the native stack.
>> - Any SyntaxError is a programmer error.
>> - Any TypeError is a programmer error.
>>
>> I expect that this will find a number of lurking errorsy, so we may want
>> to migrate code progressively, using a directive, say "use strict
>> moz-platform" and static analysis to help encourage using this directive.
>>
>> It would definitely be interesting to fail tests on some of the strict
>> failures. I was surprised when I recently turned on the pref again to see
>> how many warnings there were.
>>
>> Having looked through a few of those, I've just found at least one issue
>> , though
>> non-critical, and I'm thinking we want to get the no-unused-expressions
>>  rule turned on
>> for ESLint as a result.
>>
>> Mark
>>
>> 

Re: We need better canaries for JS code

[Chris Peterson]

On 2017-10-18 4:51 AM, Mark Banner wrote:

I expect that this will find a number of lurking errorsy, so we may want
to migrate code progressively, using a directive, say "use strict
moz-platform" and static analysis to help encourage using this directive.
It would definitely be interesting to fail tests on some of the strict 
failures. I was surprised when I recently turned on the pref again to 
see how many warnings there were.


Having looked through a few of those, I've just found at least one issue 
, though 
non-critical, and I'm thinking we want to get the no-unused-expressions 
 rule turned on 
for ESLint as a result.


Bug 1394556 just enabled strict mode by default for all JSM components 
in Firefox 57.


Bug 807862 suggested enabling strict mode by default for all builtin 
Firefox JS, but it was resolved incomplete because of concerns about 
add-on compatibility. Nosy add-ons could reach up the stack into Firefox 
JS with code like `arguments.callee.caller.caller.caller.name == 
"sss_duplicateTab"`. Perhaps that is worth revisiting now that we only 
support WebExtensions in 57+.

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

Re: We need better canaries for JS code

[Steve Fink]

On 10/18/17 10:28 AM, Boris Zbarsky wrote:

On 10/18/17 11:54 AM, David Teller wrote:

Mmmh... I was looking at setPendingException at
http://searchfox.org/mozilla-central/source/js/src/jscntxtinlines.h#435


That will allow you to hook all exceptions, sure, including ones 
caught by try/catch.



My idea would be to do it even on caught errors. It is too easy to catch
errors accidentally, in particular in Promise.


OK.  Then you need to do this in the JS engine, indeed, because catch 
happens entirely inside the JS engine. 


My gut feeling is that you'd only want uncaught errors, and 
AutoJSAPI::ReportException is a better place than setPendingException. I 
don't know how common things like


  if (eval('nightlyOnlyFeature()')) { ... }

are, but they certainly seem reasonable. And you'd have to do a bunch of 
work for every one to decide whether the catch was appropriate or not. 
It may be worth doing too, if you could come up with some robust 
whitelisting mechanisms, but at least starting with uncaught exceptions 
seems more fruitful.


As for the Promise case, I don't know enough to suggest anything, but 
surely there's a way to detect those particular issues separately? Is 
there any way to detect if a finalized Promise swallowed an exception 
without "handling" it in some way or other, even if very heuristically?



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

Re: We need better canaries for JS code

[Boris Zbarsky]

On 10/18/17 11:54 AM, David Teller wrote:

Mmmh... I was looking at setPendingException at
http://searchfox.org/mozilla-central/source/js/src/jscntxtinlines.h#435


That will allow you to hook all exceptions, sure, including ones caught 
by try/catch.



My idea would be to do it even on caught errors. It is too easy to catch
errors accidentally, in particular in Promise.


OK.  Then you need to do this in the JS engine, indeed, because catch 
happens entirely inside the JS engine.


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

Re: We need better canaries for JS code

[J. Ryan Stinnett]

This may not be what you want here, but just so you are aware of the
option...

You can use `Services.console.registerListener`[1] in a test harness, etc.
to hear messages logged to the console. The harness could count messages of
a certain type (like script errors) and fail the test if there's an
unexpected count (similar to assertion handling in some harnesses).

Some test harnesses already register console listeners, but many of them
just echo the messages to the test log without examining them further.

For JS errors logged to the console, you can QI them to nsIScriptError and
examine more details like line, column, stack, etc.

Anyway, might not cover all the cases envisioned here, but it's one tool
available to us.

[1]:
http://searchfox.org/mozilla-central/search?q=console.registerListener=true=false=

- Ryan

On Wed, Oct 18, 2017 at 6:51 AM, Mark Banner  wrote:

> Looping in firefox-dev as well, as I thin this is an important discussion.
>
> On 18/10/2017 09:28, David Teller wrote:
>
> Hi everyone,
>
>   Yesterday, Nightly was broken on Linux and MacOS because of a typo in
> JS code [1]. If I understand correctly, this triggered the usual
> "undefined is not a function", which was
>
> 1/ uncaught during testing, as these things often are;
>
> Part of the reason it was uncaught, is that there's no automated test
> coverage for that bit of code. It is a migration from one version to the
> other, but unless there is an explicit test (and I don't see one) that line
> won't be hit.
>
> This seems to be a common theme with various migration routes in the code
> base, when I've asked about ensuring more automated testing there before I
> feel like I've got shrugs.
>
> Admittedly, a lot of it is simple code, and should be correct, but as
> we've seen, mistakes can be made. Should we now be changing our policy?
>
> At a minimum, I wonder if we could write some sort of simple test for
> CustomizableUI that would go through most routes (with minimal updates for
> each change).
>
> 2/ basically impossible to diagnose in the wild, because there was no
> error message of any kind.
>
> I did an experiment, and the only way I got an error out was to have
> "javascript.options.strict" on and "browser.dom.window.dump.enabled".
> Unfortunately the breakage was such that the browser console couldn't be
> opened, so you'd just having strict on wasn't enough.
>
> I remember that we had bugs of this kind lurking for years in our
> codebase, in code that was triggered daily and that everybody believed
> to be tested.
>
> I'd like to think that there is a better way to handle these bugs,
> without waiting for them to explode in our user's face. Opening this
> thread to see if we can find a way to somehow "solve" these bugs, either
> by making them impossible, or by making them much easier to solve.
>
> ESLint has caught some bugs - mainly undefined and unused related issues,
> and is spread through most of the production javascript code. Unfortunately
> it isn't able to catch this class of error. For that, we'd need something
> like Flow. Last time I looked at it, it didn't feel like a good fit for us,
> although I didn't go too deep, and I think there may have been other people
> that were looking at it.
>
> I have one proposal. Could we change the behavior of the JS VM as follows?
>
> - The changes affect only Nightly.
> - The changes affect only mozilla chrome code (including system add-ons
> but not user add-ons or test code).
> - Any programmer error (e.g. SyntaxError) causes a crash a crash that
> displays (and attaches to the CrashReporter) both the JS stack in and
> the native stack.
> - Any SyntaxError is a programmer error.
> - Any TypeError is a programmer error.
>
> I expect that this will find a number of lurking errorsy, so we may want
> to migrate code progressively, using a directive, say "use strict
> moz-platform" and static analysis to help encourage using this directive.
>
> It would definitely be interesting to fail tests on some of the strict
> failures. I was surprised when I recently turned on the pref again to see
> how many warnings there were.
>
> Having looked through a few of those, I've just found at least one issue
> , though
> non-critical, and I'm thinking we want to get the no-unused-expressions
>  rule turned on for
> ESLint as a result.
>
> Mark
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We need better canaries for JS code

[Dave Townsend]

On Wed, Oct 18, 2017 at 4:51 AM Mark Banner  wrote:

> I remember that we had bugs of this kind lurking for years in our
> codebase, in code that was triggered daily and that everybody believed
> to be tested.
>
> I'd like to think that there is a better way to handle these bugs,
> without waiting for them to explode in our user's face. Opening this
> thread to see if we can find a way to somehow "solve" these bugs, either
> by making them impossible, or by making them much easier to solve.
>
> ESLint has caught some bugs - mainly undefined and unused related issues,
> and is spread through most of the production javascript code. Unfortunately
> it isn't able to catch this class of error. For that, we'd need something
> like Flow. Last time I looked at it, it didn't feel like a good fit for us,
> although I didn't go too deep, and I think there may have been other people
> that were looking at it.
>

As a datapoint, I've looked at both Flow and TypeScript. Both are good
tools that work well if you're writing code from scratch with them but for
existing code they flag many many pre-existing problems, the vast majority
of which aren't really problems just cases where the tools can't infer what
is going on without adding type info to the script. I came to the
conclusion that it would be too much work to use either in our main
codebase.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We need better canaries for JS code

[David Teller]

On 18/10/17 14:16, Boris Zbarsky wrote:
> On 10/18/17 4:28 AM, David Teller wrote:
>> 2/ basically impossible to diagnose in the wild, because there was no
>> error message of any kind.
> 
> That's odd.  Was the exception caught or something?  If not, it should
> have shown up in the browser console, at least

In this case, the browser console couldn't be opened. Also, as suggested
by gps, we can probably reuse the same (kind of) mechanism to report
stacks of programming errors in the wild.

> 
>> I have one proposal. Could we change the behavior of the JS VM as
>> follows?
> 
> Fwiw, the JS VM doesn't really do exception handling anymore; we handle
> all that in dom/xpconnect code.

Mmmh... I was looking at setPendingException at
http://searchfox.org/mozilla-central/source/js/src/jscntxtinlines.h#435
. Can you think of a better place to handle this?

>> - The changes affect only Nightly.
>> - The changes affect only mozilla chrome code (including system add-ons
>> but not user add-ons or test code).
> 
> What about test chrome code?  The browser and chrome mochitests are
> pretty hard to tell apart from "normal" chrome code...

Good question. I'm not sure yet. I actually don't know how the tests are
loaded, but I hope that there is a way. Also, we need to test: it is
possible that the code of tests might not be a (big) problem.

>> - Any programmer error (e.g. SyntaxError) causes a crash a crash that
>> displays (and attaches to the CrashReporter) both the JS stack in and
>> the native stack.
> 
> We would have to be a little careful to only include the chrome frames
> in the JS stack.
> 
> But the more important question is this: should this only apply to
> _uncaught_ errors, or also to ones inside try/catch?  Doing the former
> is pretty straightforward, actually.  Just hook into
> AutoJSAPI::ReportException and have it do whatever work you want.  It
> already has a concept of "chrome" (though it may not match the
> definition above; it basically goes by "system principal or not?") and
> should be the bottleneck for all uncaught exceptions, except:
> 
> * Toplevel evaluation errors (including syntax errors) in worker scripts.
> * "uncaught" promise rejections of various sorts
> 
> Doing this might be a good idea.  It's _definitely_ a good experiment...

My idea would be to do it even on caught errors. It is too easy to catch
errors accidentally, in particular in Promise.

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

Re: Intent to ship: CSP directive worker-src

[Mike West]

We do have `worker-src` tests, FWIW:
https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/worker-src/.
We'll likely need to adjust things based on the fallback mechanism y'all
are running with (and Chrome will need to drop the weird contortions we
implemented for back-compat), but I'd hope you would be able to use those
rather than writing mochitests.


-mike

On Wed, Oct 18, 2017 at 11:51 AM, Christoph Kerschbaumer  wrote:

>
> > On Oct 18, 2017, at 11:41 AM, James Graham 
> wrote:
> >
> > On 18/10/17 10:35, Christoph Kerschbaumer wrote:
> >>> On Oct 18, 2017, at 11:25 AM, James Graham 
> wrote:
> >>>
> >>> On 22/09/17 15:18, Christoph Kerschbaumer wrote:
>  Hey Everyone,
>  within CSP2 workers used to be governed by the child-src directive
> [0]. CSP3 introduces the worker-src directive [1] wich governs Workers,
> SharedWorkers as well as ServiceWorkers. Please note that the child-src
> directive has been deprecated within CSP3 in favor of worker-src as well as
> frame-src.
>  For backwards compatibility child-src will still be enforced for:
>    * workers (if worker-src is not explicitly specified)
>    * frames  (if frame-src is not explicitly specified)
>  We plan to ship the CSP directive worker-src within Firefox 58.
> >>>
> >>> Do we have cross-browser (i.e. web-platform) tests for this feature?
> >> Not yet. We just agreed with Chrome on the same fallback mechanism, see
> [1].
> >> We are about to add mochitests for all the different fallback
> mechanisms though.
> >
> > What's the reason for writing mochitests? It seems like this is
> something where we benefit from shared tests.
>
> Reason is simple, I have already written the mochitests for it. But I
> agree, we should have web-platform tests for it.
>
> ___
> 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: We need better canaries for JS code

[Boris Zbarsky]

On 10/18/17 4:28 AM, David Teller wrote:

2/ basically impossible to diagnose in the wild, because there was no
error message of any kind.


That's odd.  Was the exception caught or something?  If not, it should 
have shown up in the browser console, at least



I have one proposal. Could we change the behavior of the JS VM as follows?


Fwiw, the JS VM doesn't really do exception handling anymore; we handle 
all that in dom/xpconnect code.



- The changes affect only Nightly.
- The changes affect only mozilla chrome code (including system add-ons
but not user add-ons or test code).


What about test chrome code?  The browser and chrome mochitests are 
pretty hard to tell apart from "normal" chrome code...



- Any programmer error (e.g. SyntaxError) causes a crash a crash that
displays (and attaches to the CrashReporter) both the JS stack in and
the native stack.


We would have to be a little careful to only include the chrome frames 
in the JS stack.


But the more important question is this: should this only apply to 
_uncaught_ errors, or also to ones inside try/catch?  Doing the former 
is pretty straightforward, actually.  Just hook into 
AutoJSAPI::ReportException and have it do whatever work you want.  It 
already has a concept of "chrome" (though it may not match the 
definition above; it basically goes by "system principal or not?") and 
should be the bottleneck for all uncaught exceptions, except:


* Toplevel evaluation errors (including syntax errors) in worker scripts.
* "uncaught" promise rejections of various sorts

Doing this might be a good idea.  It's _definitely_ a good experiment...

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

Re: Intent to Unship: stream decoder for BinHex format

[Joshua Cranmer ]

On 10/17/2017 10:45 AM, Boris Zbarsky wrote:

On 10/17/17 5:47 AM, Shih-Chiang Chien wrote:

I intent to remove all the code that handling BinHex decoding, i.e.
nsBinHex.cpp, from mozilla-central if no other project is using it.


The code was originally added for mailnews.  See 
https://bugzilla.mozilla.org/show_bug.cgi?id=81352


Please double-check that this use case does not get broken, or 
condition the code to be mailnews-only or something.


FWIW, I've considered ripping out the binhex decoding from mailnews code 
anyways.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: We need better canaries for JS code

[Mark Banner]

Looping in firefox-dev as well, as I thin this is an important discussion.

On 18/10/2017 09:28, David Teller wrote:

 Hi everyone,

   Yesterday, Nightly was broken on Linux and MacOS because of a typo in
JS code [1]. If I understand correctly, this triggered the usual
"undefined is not a function", which was

1/ uncaught during testing, as these things often are;
Part of the reason it was uncaught, is that there's no automated test 
coverage for that bit of code. It is a migration from one version to the 
other, but unless there is an explicit test (and I don't see one) that 
line won't be hit.


This seems to be a common theme with various migration routes in the 
code base, when I've asked about ensuring more automated testing there 
before I feel like I've got shrugs.


Admittedly, a lot of it is simple code, and should be correct, but as 
we've seen, mistakes can be made. Should we now be changing our policy?


At a minimum, I wonder if we could write some sort of simple test for 
CustomizableUI that would go through most routes (with minimal updates 
for each change).



2/ basically impossible to diagnose in the wild, because there was no
error message of any kind.
I did an experiment, and the only way I got an error out was to have 
"javascript.options.strict" on and "browser.dom.window.dump.enabled". 
Unfortunately the breakage was such that the browser console couldn't be 
opened, so you'd just having strict on wasn't enough.

I remember that we had bugs of this kind lurking for years in our
codebase, in code that was triggered daily and that everybody believed
to be tested.

I'd like to think that there is a better way to handle these bugs,
without waiting for them to explode in our user's face. Opening this
thread to see if we can find a way to somehow "solve" these bugs, either
by making them impossible, or by making them much easier to solve.
ESLint has caught some bugs - mainly undefined and unused related 
issues, and is spread through most of the production javascript code. 
Unfortunately it isn't able to catch this class of error. For that, we'd 
need something like Flow. Last time I looked at it, it didn't feel like 
a good fit for us, although I didn't go too deep, and I think there may 
have been other people that were looking at it.

I have one proposal. Could we change the behavior of the JS VM as follows?

- The changes affect only Nightly.
- The changes affect only mozilla chrome code (including system add-ons
but not user add-ons or test code).
- Any programmer error (e.g. SyntaxError) causes a crash a crash that
displays (and attaches to the CrashReporter) both the JS stack in and
the native stack.
- Any SyntaxError is a programmer error.
- Any TypeError is a programmer error.

I expect that this will find a number of lurking errorsy, so we may want
to migrate code progressively, using a directive, say "use strict
moz-platform" and static analysis to help encourage using this directive.
It would definitely be interesting to fail tests on some of the strict 
failures. I was surprised when I recently turned on the pref again to 
see how many warnings there were.


Having looked through a few of those, I've just found at least one issue 
, though 
non-critical, and I'm thinking we want to get the no-unused-expressions 
 rule turned on 
for ESLint as a result.


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

Re: We need better canaries for JS code

[David Teller]

> I'm not sure changing behavior of the JS VM is the proper layer to
> accomplish this. I think reporting messages from the JS console is a
> better place to start. We could change the test harnesses to fail tests
> if certain errors (like SyntaxError or TypeError) are raised. If there
> is a "hook" in the JS VM to catch said errors at error time, we could
> have the test harnesses run Firefox in a mode that makes said errors
> more fatal (even potentially crashing as you suggest) and/or included
> additional metadata, such as stacks.

Ok, I discussed this with jorendorff.

It shouldn't be too hard to add this hook, plus it should have basically
no overhead. The next step would be to register a test harness handler
to crash (or do something else).

This would later open the door to reporting errors (possibly through
crashing) from Nightly, Beta, Release, ...

My main worry, at this stage, is what we encountered when we started
flagging uncaught async errors: some module owners simply never fixed
their errors, so we had to whitelist large swaths of Firefox code,
knowing that it was misbehaving.


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

Re: Intent to ship: CSP directive worker-src

[Christoph Kerschbaumer]

> On Oct 18, 2017, at 11:41 AM, James Graham  wrote:
> 
> On 18/10/17 10:35, Christoph Kerschbaumer wrote:
>>> On Oct 18, 2017, at 11:25 AM, James Graham  wrote:
>>> 
>>> On 22/09/17 15:18, Christoph Kerschbaumer wrote:
 Hey Everyone,
 within CSP2 workers used to be governed by the child-src directive [0]. 
 CSP3 introduces the worker-src directive [1] wich governs Workers, 
 SharedWorkers as well as ServiceWorkers. Please note that the child-src 
 directive has been deprecated within CSP3 in favor of worker-src as well 
 as frame-src.
 For backwards compatibility child-src will still be enforced for:
   * workers (if worker-src is not explicitly specified)
   * frames  (if frame-src is not explicitly specified)
 We plan to ship the CSP directive worker-src within Firefox 58.
>>> 
>>> Do we have cross-browser (i.e. web-platform) tests for this feature?
>> Not yet. We just agreed with Chrome on the same fallback mechanism, see [1].
>> We are about to add mochitests for all the different fallback mechanisms 
>> though.
> 
> What's the reason for writing mochitests? It seems like this is something 
> where we benefit from shared tests.

Reason is simple, I have already written the mochitests for it. But I agree, we 
should have web-platform tests for it.

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

Re: We need better canaries for JS code

[David Teller]

On 18/10/17 10:45, Gregory Szorc wrote:
> I agree that errors like this should have better visibility in order to
> help catch bugs.
> 
> I'm not sure changing behavior of the JS VM is the proper layer to
> accomplish this. I think reporting messages from the JS console is a
> better place to start. We could change the test harnesses to fail tests
> if certain errors (like SyntaxError or TypeError) are raised. If there
> is a "hook" in the JS VM to catch said errors at error time, we could
> have the test harnesses run Firefox in a mode that makes said errors
> more fatal (even potentially crashing as you suggest) and/or included
> additional metadata, such as stacks.

Works for me. I'd need to check how much performance this would cost.

> Another idea would be to require all non-log output in the JS console to
> be accounted for. Kinda like reftest's expected assertion count.
> Assuming most JS errors/warnings are unwanted, this would allow us to
> fail all tests reporting JS errors/warnings while allowing wanted/known
> failures to not fail the test. A problem though is background services
> "randomly" injecting their output during test execution depending on
> non-deterministic timing. It could be difficult to roll this out in
> practice. But it feels like we should be able to filter out messages or
> stacks accordingly.

This looks like a much larger undertaking.

> But why stop there? Shouldn't Firefox installs in the wild report JS
> errors and warnings in Firefox code back to Mozilla (like we do
> crashes)? I know this has been discussed. I'm not sure what we're
> doing/planning about it though.

I would be for it, but as a followup.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

[Masayuki Nakano]

On 10/18/2017 4:08 PM, Jet Villegas wrote:

That is, do I owe you another steak? :-)


Always welcome another steak :-D

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We need better canaries for JS code

[Gregory Szorc]

On Wed, Oct 18, 2017 at 10:28 AM, David Teller  wrote:

> Hi everyone,
>
>   Yesterday, Nightly was broken on Linux and MacOS because of a typo in
> JS code [1]. If I understand correctly, this triggered the usual
> "undefined is not a function", which was
>
> 1/ uncaught during testing, as these things often are;
> 2/ basically impossible to diagnose in the wild, because there was no
> error message of any kind.
>
> I remember that we had bugs of this kind lurking for years in our
> codebase, in code that was triggered daily and that everybody believed
> to be tested.
>
> I'd like to think that there is a better way to handle these bugs,
> without waiting for them to explode in our user's face. Opening this
> thread to see if we can find a way to somehow "solve" these bugs, either
> by making them impossible, or by making them much easier to solve.
>
> I have one proposal. Could we change the behavior of the JS VM as follows?
>
> - The changes affect only Nightly.
> - The changes affect only mozilla chrome code (including system add-ons
> but not user add-ons or test code).
> - Any programmer error (e.g. SyntaxError) causes a crash a crash that
> displays (and attaches to the CrashReporter) both the JS stack in and
> the native stack.
> - Any SyntaxError is a programmer error.
> - Any TypeError is a programmer error.
>
> I expect that this will find a number of lurking errorsy, so we may want
> to migrate code progressively, using a directive, say "use strict
> moz-platform" and static analysis to help encourage using this directive.
>
> What do you think?
>

I agree that errors like this should have better visibility in order to
help catch bugs.

I'm not sure changing behavior of the JS VM is the proper layer to
accomplish this. I think reporting messages from the JS console is a better
place to start. We could change the test harnesses to fail tests if certain
errors (like SyntaxError or TypeError) are raised. If there is a "hook" in
the JS VM to catch said errors at error time, we could have the test
harnesses run Firefox in a mode that makes said errors more fatal (even
potentially crashing as you suggest) and/or included additional metadata,
such as stacks.

Another idea would be to require all non-log output in the JS console to be
accounted for. Kinda like reftest's expected assertion count. Assuming most
JS errors/warnings are unwanted, this would allow us to fail all tests
reporting JS errors/warnings while allowing wanted/known failures to not
fail the test. A problem though is background services "randomly" injecting
their output during test execution depending on non-deterministic timing.
It could be difficult to roll this out in practice. But it feels like we
should be able to filter out messages or stacks accordingly.

But why stop there? Shouldn't Firefox installs in the wild report JS errors
and warnings in Firefox code back to Mozilla (like we do crashes)? I know
this has been discussed. I'm not sure what we're doing/planning about it
though.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSP directive worker-src

[James Graham]

On 18/10/17 10:35, Christoph Kerschbaumer wrote:



On Oct 18, 2017, at 11:25 AM, James Graham  wrote:

On 22/09/17 15:18, Christoph Kerschbaumer wrote:

Hey Everyone,
within CSP2 workers used to be governed by the child-src directive [0]. CSP3 
introduces the worker-src directive [1] wich governs Workers, SharedWorkers as 
well as ServiceWorkers. Please note that the child-src directive has been 
deprecated within CSP3 in favor of worker-src as well as frame-src.
For backwards compatibility child-src will still be enforced for:
   * workers (if worker-src is not explicitly specified)
   * frames  (if frame-src is not explicitly specified)
We plan to ship the CSP directive worker-src within Firefox 58.


Do we have cross-browser (i.e. web-platform) tests for this feature?


Not yet. We just agreed with Chrome on the same fallback mechanism, see [1].
We are about to add mochitests for all the different fallback mechanisms though.


What's the reason for writing mochitests? It seems like this is 
something where we benefit from shared tests.

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

Re: Intent to ship: CSP directive worker-src

[Christoph Kerschbaumer]

> On Oct 18, 2017, at 11:25 AM, James Graham  wrote:
> 
> On 22/09/17 15:18, Christoph Kerschbaumer wrote:
>> Hey Everyone,
>> within CSP2 workers used to be governed by the child-src directive [0]. CSP3 
>> introduces the worker-src directive [1] wich governs Workers, SharedWorkers 
>> as well as ServiceWorkers. Please note that the child-src directive has been 
>> deprecated within CSP3 in favor of worker-src as well as frame-src.
>> For backwards compatibility child-src will still be enforced for:
>>   * workers (if worker-src is not explicitly specified)
>>   * frames  (if frame-src is not explicitly specified)
>> We plan to ship the CSP directive worker-src within Firefox 58.
> 
> Do we have cross-browser (i.e. web-platform) tests for this feature?

Not yet. We just agreed with Chrome on the same fallback mechanism, see [1].
We are about to add mochitests for all the different fallback mechanisms though.

[1] https://github.com/w3c/webappsec-csp/issues/239#issuecomment-337488401

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

Re: Intent to ship: CSP directive worker-src

[James Graham]

On 22/09/17 15:18, Christoph Kerschbaumer wrote:

Hey Everyone,

within CSP2 workers used to be governed by the child-src directive [0]. CSP3 
introduces the worker-src directive [1] wich governs Workers, SharedWorkers as 
well as ServiceWorkers. Please note that the child-src directive has been 
deprecated within CSP3 in favor of worker-src as well as frame-src.

For backwards compatibility child-src will still be enforced for:
   * workers (if worker-src is not explicitly specified)
   * frames  (if frame-src is not explicitly specified)

We plan to ship the CSP directive worker-src within Firefox 58.


Do we have cross-browser (i.e. web-platform) tests for this feature?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We need better canaries for JS code

[Gabriele Svelto]

On 18/10/2017 10:28, David Teller wrote:
> I have one proposal. Could we change the behavior of the JS VM as follows?
> 
> - The changes affect only Nightly.
> - The changes affect only mozilla chrome code (including system add-ons
> but not user add-ons or test code).
> - Any programmer error (e.g. SyntaxError) causes a crash a crash that
> displays (and attaches to the CrashReporter) both the JS stack in and
> the native stack.
> - Any SyntaxError is a programmer error.
> - Any TypeError is a programmer error.

I'd love to have that, even only on try it would catch a lot of stuff.
BTW the problem of errors in JS code not affecting test results in any
way is very widespread. We have plenty of tests spewing out actual
errors (often only when certain races occur and objects/functions become
undefined) that have no visible impact on the test results themselves
since they're ignored.

 Gabriele



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

Re: Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

[smaug]

On 10/18/2017 08:08 AM, Jet Villegas wrote:

SGTM. BTW, bug 143038 was filed 16 years ago. Is that a bugzilla record for
oldest fixed bug?


whoohoo, didn't realize it was that old.
One day I'll start reading the bugs I review ;)




That is, do I owe you another steak? :-)


On Wed, Oct 18, 2017 at 2:52 PM, Masayuki Nakano 
wrote:


From some users who use legacy mice which supports only vertical wheel, we
have a request to support horizontal scroll with vertical wheel operation
with a modifier.
https://bugzilla.mozilla.org/show_bug.cgi?id=143038

Now, legacy add-ons have gone since 57 and it may be difficult to override
default action of wheel events with WebExtensions, it is the time to
support horizontal scroll with vertical wheel operation with Shift key.

This will be enabled in default settings except on macOS.  The reason why
we don't need to use this feature on macOS is, macOS generates horizontal
wheel event if user uses legacy mouse and pressing Shift key.

And default action of wheel with Alt key is changed to history navigation
which is default action of wheel with Shift key in current release build.

So, now, we have consistent behavior between Firefox for macOS and the
others.

Note that this feature won't be exposed to attributes of "wheel" events.
This is just a default action change and same behavior as Chrome.

--
Masayuki Nakano 
Software Engineer, Mozilla
___
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

We need better canaries for JS code

[David Teller]

Hi everyone,

  Yesterday, Nightly was broken on Linux and MacOS because of a typo in
JS code [1]. If I understand correctly, this triggered the usual
"undefined is not a function", which was

1/ uncaught during testing, as these things often are;
2/ basically impossible to diagnose in the wild, because there was no
error message of any kind.

I remember that we had bugs of this kind lurking for years in our
codebase, in code that was triggered daily and that everybody believed
to be tested.

I'd like to think that there is a better way to handle these bugs,
without waiting for them to explode in our user's face. Opening this
thread to see if we can find a way to somehow "solve" these bugs, either
by making them impossible, or by making them much easier to solve.

I have one proposal. Could we change the behavior of the JS VM as follows?

- The changes affect only Nightly.
- The changes affect only mozilla chrome code (including system add-ons
but not user add-ons or test code).
- Any programmer error (e.g. SyntaxError) causes a crash a crash that
displays (and attaches to the CrashReporter) both the JS stack in and
the native stack.
- Any SyntaxError is a programmer error.
- Any TypeError is a programmer error.

I expect that this will find a number of lurking errorsy, so we may want
to migrate code progressively, using a directive, say "use strict
moz-platform" and static analysis to help encourage using this directive.

What do you think?

Cheers,
 David



[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1407351#c28
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

[Jet Villegas]

SGTM. BTW, bug 143038 was filed 16 years ago. Is that a bugzilla record for
oldest fixed bug?

That is, do I owe you another steak? :-)


On Wed, Oct 18, 2017 at 2:52 PM, Masayuki Nakano 
wrote:

> From some users who use legacy mice which supports only vertical wheel, we
> have a request to support horizontal scroll with vertical wheel operation
> with a modifier.
> https://bugzilla.mozilla.org/show_bug.cgi?id=143038
>
> Now, legacy add-ons have gone since 57 and it may be difficult to override
> default action of wheel events with WebExtensions, it is the time to
> support horizontal scroll with vertical wheel operation with Shift key.
>
> This will be enabled in default settings except on macOS.  The reason why
> we don't need to use this feature on macOS is, macOS generates horizontal
> wheel event if user uses legacy mouse and pressing Shift key.
>
> And default action of wheel with Alt key is changed to history navigation
> which is default action of wheel with Shift key in current release build.
>
> So, now, we have consistent behavior between Firefox for macOS and the
> others.
>
> Note that this feature won't be exposed to attributes of "wheel" events.
> This is just a default action change and same behavior as Chrome.
>
> --
> Masayuki Nakano 
> Software Engineer, Mozilla
> ___
> 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: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

[Masayuki Nakano]

From some users who use legacy mice which supports only vertical wheel, 
we have a request to support horizontal scroll with vertical wheel 
operation with a modifier.

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

Now, legacy add-ons have gone since 57 and it may be difficult to 
override default action of wheel events with WebExtensions, it is the 
time to support horizontal scroll with vertical wheel operation with 
Shift key.


This will be enabled in default settings except on macOS.  The reason 
why we don't need to use this feature on macOS is, macOS generates 
horizontal wheel event if user uses legacy mouse and pressing Shift key.


And default action of wheel with Alt key is changed to history 
navigation which is default action of wheel with Shift key in current 
release build.


So, now, we have consistent behavior between Firefox for macOS and the 
others.


Note that this feature won't be exposed to attributes of "wheel" events. 
This is just a default action change and same behavior as Chrome.


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform