Re: Intent to implement and ship: isSecureContext attribute on workers

[Ben Kelly]

On Sep 23, 2016 9:15 PM, "Boris Zbarsky"
> Concerns: No one else implements this so far, and it does add one
interesting requirement: it requires that shared workers not be shared
between secure and insecure contexts.  Whichever one creates the shared
worker first wins; the other creation attempt throws.  It _may_ be better
to have an error event here instead of an exception (akin to what we do for
origin mismatches on the worker url).  It may also turn out that not
creating the shared worker in this situation creates a compat issue...  So
far I haven't been able to figure out a sane way to test whether Chrome
does the shared worker thing (which it might do even though it doesn't
implement the DOM API).

Some spec discussion for this is here btw:

https://github.com/w3c/webappsec/issues/406

To be honest I don't love the order dependent nature of this.  If I had my
druthers I'd rather just restrict `new SharedWorker()` to secure contexts
completely.  If you can't use the API from insecure contexts the problem
goes away.

Given some people think SharedWorker can be removed completely, it might
not even be a compat problem.  (Safari removed SharedWorker and no one
noticed...)

By the same argument, though, I should probably just not worry about this
API corner case.

So looks good to me.

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

Intent to implement and ship: isSecureContext attribute on workers

[Boris Zbarsky]

Summary: This gives workers an isSecureContext property on the global, 
like we already have for windows.


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

Spec: 
https://w3c.github.io/webappsec-secure-contexts/#monkey-patching-global-object 
and https://w3c.github.io/webappsec-secure-contexts/#settings-object step 2.


Estimated or target release: Firefox 52.

Preference: None for now, but see below.

Devtools bug: None needed, I believe.

Support in other browsers: None so far.  I thought Chrome had this 
implemented but it doesn't seem to.


Tests: Included in the patch.

Concerns: No one else implements this so far, and it does add one 
interesting requirement: it requires that shared workers not be shared 
between secure and insecure contexts.  Whichever one creates the shared 
worker first wins; the other creation attempt throws.  It _may_ be 
better to have an error event here instead of an exception (akin to what 
we do for origin mismatches on the worker url).  It may also turn out 
that not creating the shared worker in this situation creates a compat 
issue...  So far I haven't been able to figure out a sane way to test 
whether Chrome does the shared worker thing (which it might do even 
though it doesn't implement the DOM API).


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

Re: Firefox Engineering TMO Survey

[Ryan VanderMeulen]

Looks like the body of the email got lost!

In order to make telemetry.mozilla.org (TMO) and related sites a tool 
that better supports the needs of the Firefox engineering teams, we 
would like to collect feedback about people's experiences using these 
tools. It shouldn't take more than a few minutes and responses are 
welcome whether it's a tool you've personally used before or not.


Thank you for your time!

-Ryan

On 9/23/2016 3:23 PM, rvandermeu...@mozilla.com wrote:

I've invited you to fill out the following form:
Firefox Engineering TMO Survey

To fill it out, visit:
https://docs.google.com/forms/d/e/1FAIpQLSfu_8RosGp9_yNNc1m0Nn6Un9KD3P9yClUob6x9tnPbv1iIJw/viewform?c=0w=1usp=mail_form_link


Google Forms: Create and analyze surveys.


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

Firefox Engineering TMO Survey

[rvandermeulen]

I've invited you to fill out the following form:
Firefox Engineering TMO Survey

To fill it out, visit:
https://docs.google.com/forms/d/e/1FAIpQLSfu_8RosGp9_yNNc1m0Nn6Un9KD3P9yClUob6x9tnPbv1iIJw/viewform?c=0w=1usp=mail_form_link

Google Forms: Create and analyze surveys.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Buildbot Try artifact expiration

[garndt]

> Just to be clear, what counts as "artifacts" here?  The actual build? 
> The log?  All of the above?

For taskcluster, starting in May, the entire task would be expired, including 
any output from it (artifacts, logs, etc). If you look at a taskcluster task on 
try from August you will see that the task no longer exists.  However, if this 
default was ever a problem for a certain task, or if you want tasks from your 
push to try to live for longer, all of the task definitions live in tree, and 
you can update them to have a different default expiration.

Here is an example from our task transform logic.  Basically the task would 
need to define "expires-after".

https://dxr.mozilla.org/mozilla-central/source/taskcluster/taskgraph/transforms/task.py?q=taskcluster%2Ftaskgraph%2Ftransforms%2Ftask.py_type=direct#485


For buildbot try jobs, expiring artifacts older than 14 days is any file that 
buildbot or mozharness created using TaskCluster.  I'm not sure if buildbot 
itself is doing anything to upload through TaskCluster, but mozharness based 
actions definitely do.  This could include logs.

What we are wanting to do is retroactively expire buildbot try artifacts (which 
may include some logs) older than 14 days, as well as expire TaskCluster try 
artifacts created before May that are still lingering around before we made 
this default behavior.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

[Michael Layzell]

We already have implemented that static analysis but haven't enabled it
yet, because static analysis doesn't run on windows machines:
https://bugzilla.mozilla.org/show_bug.cgi?id=1223932

On Fri, Sep 23, 2016 at 12:51 PM, Bobby Holley 
wrote:

> On Fri, Sep 23, 2016 at 9:30 AM, Ted Mielczarek 
> wrote:
>
> > On Fri, Sep 23, 2016, at 10:20 AM, Ehsan Akhgari wrote:
> > > On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote:
> > > > Then this enables me to answer Ehsan's question. These are the builds
> > > > I've recently tried using (e.g. when debugging intermittents in VMs
> > > > because then I don't need to set up too much of a build env) and
> > they're
> > > > still very slow.
> > >
> > > Unfortunately I don't think we can do debug builds that are faster than
> > > that.  It's possible that the debugging checks that we perform in the
> > > cases you're trying to use the browser in are just prohibitively too
> > > expensive.  :(
> >
> > If someone had time, it might be interesting to profile something that
> > feels slow in an --enable-debug --enable-optimize build and see if
> > anything stands out. These builds will always be a little slower than
> > the builds we ship (because they're not PGOed), but it would be nice if
> > they were at least usable. Making them faster would also make our debug
> > test runs in automation faster, which is a nice win! (We spend *a lot*
> > of CPU time running debug tests in automation.)
> >
>
> Nathan looked at this a few years ago:
> https://bugzilla.mozilla.org/show_bug.cgi?id=972135
>
> There's some low-hanging fruit for anyone with static analysis savvy.
>
>
> >
> > -Ted
> >
> > ___
> > 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: Converting assertions into release assertions

[Bobby Holley]

On Fri, Sep 23, 2016 at 9:30 AM, Ted Mielczarek  wrote:

> On Fri, Sep 23, 2016, at 10:20 AM, Ehsan Akhgari wrote:
> > On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote:
> > > Then this enables me to answer Ehsan's question. These are the builds
> > > I've recently tried using (e.g. when debugging intermittents in VMs
> > > because then I don't need to set up too much of a build env) and
> they're
> > > still very slow.
> >
> > Unfortunately I don't think we can do debug builds that are faster than
> > that.  It's possible that the debugging checks that we perform in the
> > cases you're trying to use the browser in are just prohibitively too
> > expensive.  :(
>
> If someone had time, it might be interesting to profile something that
> feels slow in an --enable-debug --enable-optimize build and see if
> anything stands out. These builds will always be a little slower than
> the builds we ship (because they're not PGOed), but it would be nice if
> they were at least usable. Making them faster would also make our debug
> test runs in automation faster, which is a nice win! (We spend *a lot*
> of CPU time running debug tests in automation.)
>

Nathan looked at this a few years ago:
https://bugzilla.mozilla.org/show_bug.cgi?id=972135

There's some low-hanging fruit for anyone with static analysis savvy.


>
> -Ted
>
> ___
> 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: Storage API estimate method

[smaug]

On 09/22/2016 02:57 AM, Andrew Overholt wrote:

On Thu, Sep 22, 2016 at 2:03 AM, smaug  wrote:



On 09/21/2016 04:42 AM, Shawn Huang wrote:



​Because ​Storage API needs to have SecureContext support, but currently
not having isSecureContext available in Workers (bug 1269052) is
problematic. Can we initially release the Storage API without Worker
support?



That sounds a tad worrisome. Is there a reason why we can't wait until we
have SecureContext also in workers?



I encouraged Shawn to send this to gauge people's thoughts on whether we
could ship without Worker support. It seems you're on the side of waiting
until we have SecureContext support in Workers :)


Right. And bz said today that he has the patch ready for SecureContext in workers and was 
missing "just" some tests.

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

Re: Converting assertions into release assertions

[Ted Mielczarek]

On Fri, Sep 23, 2016, at 10:20 AM, Ehsan Akhgari wrote:
> On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote:
> > Then this enables me to answer Ehsan's question. These are the builds
> > I've recently tried using (e.g. when debugging intermittents in VMs
> > because then I don't need to set up too much of a build env) and they're
> > still very slow.
> 
> Unfortunately I don't think we can do debug builds that are faster than
> that.  It's possible that the debugging checks that we perform in the
> cases you're trying to use the browser in are just prohibitively too
> expensive.  :(

If someone had time, it might be interesting to profile something that
feels slow in an --enable-debug --enable-optimize build and see if
anything stands out. These builds will always be a little slower than
the builds we ship (because they're not PGOed), but it would be nice if
they were at least usable. Making them faster would also make our debug
test runs in automation faster, which is a nice win! (We spend *a lot*
of CPU time running debug tests in automation.)

-Ted

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

Re: Converting assertions into release assertions

[Ehsan Akhgari]

On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote:
> On 23/09/2016 11:20, Ted Mielczarek wrote:
>> On Fri, Sep 23, 2016, at 05:58 AM, Panos Astithas wrote:
>>> I used to do that in the past, but nowadays artifact builds have changed
>>> the cost-benefit trade-off so very few people bother AFAIK, when not
>>> touching C++ code. If we could get artifact builds to use --enable-debug
>>> and --enable-optimize (or have an option to do so) that could change the
>>> calculus.
>>
>> The debug builds we do in automation are already built with optimization
>> (we changed this a few years ago to speed up running tests), so it ought
>> to be straightforward to make debug artifact builds work by fetching
>> those bits.
>>
>> -Ted
> 
> Then this enables me to answer Ehsan's question. These are the builds
> I've recently tried using (e.g. when debugging intermittents in VMs
> because then I don't need to set up too much of a build env) and they're
> still very slow.

Unfortunately I don't think we can do debug builds that are faster than
that.  It's possible that the debugging checks that we perform in the
cases you're trying to use the browser in are just prohibitively too
expensive.  :(
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

[Ehsan Akhgari]

On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote:
> On 23/09/2016 11:20, Ted Mielczarek wrote:
>> On Fri, Sep 23, 2016, at 05:58 AM, Panos Astithas wrote:
>>> I used to do that in the past, but nowadays artifact builds have changed
>>> the cost-benefit trade-off so very few people bother AFAIK, when not
>>> touching C++ code. If we could get artifact builds to use --enable-debug
>>> and --enable-optimize (or have an option to do so) that could change the
>>> calculus.
>>
>> The debug builds we do in automation are already built with optimization
>> (we changed this a few years ago to speed up running tests), so it ought
>> to be straightforward to make debug artifact builds work by fetching
>> those bits.
>>
>> -Ted
> 
> Then this enables me to answer Ehsan's question. These are the builds
> I've recently tried using (e.g. when debugging intermittents in VMs
> because then I don't need to set up too much of a build env) and they're
> still very slow.

Unfortunately I don't think we can do debug builds that are faster than
that.  It's possible that the debugging checks that we perform in the
cases you're trying to use the browser in are just prohibitively too
expensive.  :(
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

[Paolo Amadini]

On 9/23/2016 1:49 PM, Gijs Kruitbosch wrote:

Then this enables me to answer Ehsan's question. These are the builds
I've recently tried using (e.g. when debugging intermittents in VMs
because then I don't need to set up too much of a build env) and they're
still very slow.


Some time ago I ventilated the idea of having a build mode that enables
debug for everything except the JavaScript engine itself, but the
conclusion was that there wasn't a strong need for it as we could just
use the non-debug optimized build for front-end development.

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

Re: Converting assertions into release assertions

[Gijs Kruitbosch]

On 23/09/2016 11:20, Ted Mielczarek wrote:

On Fri, Sep 23, 2016, at 05:58 AM, Panos Astithas wrote:

I used to do that in the past, but nowadays artifact builds have changed
the cost-benefit trade-off so very few people bother AFAIK, when not
touching C++ code. If we could get artifact builds to use --enable-debug
and --enable-optimize (or have an option to do so) that could change the
calculus.


The debug builds we do in automation are already built with optimization
(we changed this a few years ago to speed up running tests), so it ought
to be straightforward to make debug artifact builds work by fetching
those bits.

-Ted


Then this enables me to answer Ehsan's question. These are the builds 
I've recently tried using (e.g. when debugging intermittents in VMs 
because then I don't need to set up too much of a build env) and they're 
still very slow.


You can use debug builds from artifact mode using the MOZ_DEBUG switch 
in your mozconfig (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1253697 - annoyingly, last 
I tried, just --enable-debug isn't good enough to download debug bits, 
see also the patch that landed for that bug).


~ Gijs

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

Re: Intent to ship: Storage API estimate method

[Xidorn Quan]

On Wed, Sep 21, 2016, at 01:42 PM, Shawn Huang wrote:
> Summary:
> ​The Storage Standard defines an API for persistent storage and quota
> estimates.
> ​The estimate()
>  method can
> be used to determine whether there is enough space left to download,
> estimate() method returns both usage and quota per a origin.

How is the quota of an origin decided? Is that something depends on
user's disk capacity or it's just a fixed value? Would that expose new
fingerprint?

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

Re: Converting assertions into release assertions

[Ted Mielczarek]

On Fri, Sep 23, 2016, at 05:58 AM, Panos Astithas wrote:
> I used to do that in the past, but nowadays artifact builds have changed
> the cost-benefit trade-off so very few people bother AFAIK, when not
> touching C++ code. If we could get artifact builds to use --enable-debug
> and --enable-optimize (or have an option to do so) that could change the
> calculus.

The debug builds we do in automation are already built with optimization
(we changed this a few years ago to speed up running tests), so it ought
to be straightforward to make debug artifact builds work by fetching
those bits.

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

Re: Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

[ishikawa]

On 2016年09月23日 15:53, Mark Banner wrote:
> 
> https://dxr.mozilla.org/mozilla-central/search?q=security.turn_off_all_security_so_that_viruses_can_take_over_this_computer=false
> 
> 
> This probably means that the Thunderbird specific MozMill builders should
> either not be installing the special powers add-on (which I suspect is
> hard), or they should also be setting the pref to true.
> 

I thin I will set the pref to true and test the try-comm-central again.

>> I changed only these:
> 
> There's no need to include a full diff when you've already linked to it.
> 

Right. I will create a bugzilla to discuss this.

> Mark.

Thank you again.

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

Re: Converting assertions into release assertions

[Panos Astithas]

On Thu, Sep 22, 2016 at 6:07 PM, Ehsan Akhgari 
wrote:

> On 2016-09-22 9:07 AM, Gijs Kruitbosch wrote:
> > On 22/09/2016 05:28, Nicholas Nethercote wrote:
> >> Greetings,
> >>
> >> Assertions, such as MOZ_ASSERT, are great. But they only run in debug
> >> builds.
> >>
> >> Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
> >>
> >> I want to highlight a nice case where converting a normal assertion
> >> into a release assertion was a win. In bug 1159244 Michael Layzell did
> >> this in nsTArray::ElementAt(), to implement a form of always-on array
> >> bounds checking. See
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for
> >> discussion of how this is finding real bugs in the wild. (As well as
> >> identifying new bugs, it's also helping understand existing crash
> >> reports, e.g. see bug 1291082 where the crash signature changed.)
> >>
> >> Obviously we can't convert every normal assertion in the codebase into
> >> a release assertion. But it might be worth thinking about which normal
> >> assertions are good candidates for conversion. Good candidates include
> >> any assertion where the consequence of failure is dangerous, e.g.
> >> might cause memory access violations.
> >>
> >> Nick
> >
> > Yes please. This + diagnostic assert also helps frontend people who
> > build and run opt builds (because debug builds are too slow to be
> > usable, especially when combined with the browser toolbox (JS
> > debugging)). Right now I miss some of these and then only find out when
> > the tests that I did run go orange on try and/or inbound/autoland, and
> > then I have to locally change the relevant C++ so I can test in my opt
> > build (or resign myself to doing a separate clobber debug build
> somewhere).
>
> What exact debug configuration is too slow for you?  People who want to
> debug C++ generally turn optimizations off, but for front-end devs, I
> think building with --enable-debug and --enable-optimize should give you
> an optimized build with the debug facilities turned on, which should be
> much faster.  Although it is not going to be as fast as a
> --disable-debug --enable-optimize build, there's a lot of value in
> Mozilla developers running builds with debug checks turned on, so that
> we can get good bug reports when an assertion fires when working on a
> front-end feature, etc.
>

I used to do that in the past, but nowadays artifact builds have changed
the cost-benefit trade-off so very few people bother AFAIK, when not
touching C++ code. If we could get artifact builds to use --enable-debug
and --enable-optimize (or have an option to do so) that could change the
calculus.

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

B2G OS Announcements on Tuesday

[Benjamin Francis]

Dear B2G OS community,

Our weekly meeting on Tuesday 27th September will be attended by some
senior members of staff from Mozilla who would like to make some
announcements to the community about the future of the B2G project and
Mozilla's involvement.

I would strongly recommend that you attend if you can as this will be your
opportunity to hear those announcements first hand and to ask any questions
you may have.

You can join the meeting by using the usual guest link 
which requires Vidyo  to join the B2G Vidyo room.
The meeting is at *9am PT (Pacific Time) on Tuesday 27th September*, full
details are on the wiki .

Meeting notes will be kept on the Etherpad
 as usual. Back
channel chat is on the #b2g IRC channel (which is mirrored to Telegram).
This week the meeting will also be streamed on Air Mozilla
 and you can submit questions via IRC if you
prefer.

Regards

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

Re: Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

[Mark Banner]

On 23/09/2016 05:01, ishikawa wrote:

On 2016年09月23日 11:42, ishikawa wrote:


By changing a few install.rdf as suggested, the particular error messages
are gone, but
I now see different failures.

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central=de72a169065a2bbb7f69a0e5420992bfca5a77ec

I am testing other patches as well, the particular patch to modify
install.rdf is
https://hg.mozilla.org/try-comm-central/rev/a135ec33cb11

I will investigate more to see if the new errors are due to my changes or
a regression caused by a later change to M-C, etc.




The new errors are obviously related to my change.

...


inline void
CrashIfNotInAutomation()
{
MOZ_RELEASE_ASSERT(IsInAutomation());
}

So where is CrashIfNotInAutomation() called?


Did you look at the IsInAutomation() function?

https://dxr.mozilla.org/mozilla-central/rev/f0e6cc6360213ba21fd98c887b55fce5c680df68/js/xpconnect/src/xpcpublic.h#606

That's clearly checking a preference that is expected for automation. 
Looking at the tree, it gets set to true for most (probably all) of the 
tests that Firefox runs:


https://dxr.mozilla.org/mozilla-central/search?q=security.turn_off_all_security_so_that_viruses_can_take_over_this_computer=false

This probably means that the Thunderbird specific MozMill builders 
should either not be installing the special powers add-on (which I 
suspect is hard), or they should also be setting the pref to true.



I changed only these:


There's no need to include a full diff when you've already linked to it.

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

Re: Converting assertions into release assertions

[Julian Seward]

On 22/09/16 17:07, Ehsan Akhgari wrote:

> What exact debug configuration is too slow for you?  People who want to
> debug C++ generally turn optimizations off, but for front-end devs, I
> think building with --enable-debug and --enable-optimize should give you
> an optimized build with the debug facilities turned on, which should be
> much faster.

At least with recent-ish gccs on Linux, --enable-optimize="-Og -g" provides
quite significant optimization but with the compiler making efforts to
retain good debuggability of the generated code.  At least with GDB it
is quite feasible to navigate around in -Og compiled code.  I use -Og a
lot; it's a good compromise.

J

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