Re: Proposed W3C Charter: Hardware Security Working Group

[Eric Rescorla]

Richard,

Is an browser actually interested in implementing the output of this WG?

-Ekr


On Tue, Mar 1, 2016 at 3:32 PM, Richard Barnes  wrote:

> Mozilla should oppose the formation of this working group.  The charter
> fails to specify concrete deliverables, and many of the potential
> deliverables listed have been opposed several times by browser vendors,
> e.g., because hardware assets exposed to JS can be used as super-cookies.
>
> If anything is to be done here, it should be done in a community group or
> other forum until they have a story for what exactly they will be
> developing and how it fits with the web security model.
>
> On Mon, Feb 29, 2016 at 8:34 PM, L. David Baron  wrote:
>
> > The W3C is proposing a charter for:
> >
> >   Hardware Security Working Group
> >   https://www.w3.org/2015/hasec/2015-hasec-charter.html
> >   https://lists.w3.org/Archives/Public/public-new-work/2016Feb/0009.html
> >
> > Mozilla has the opportunity to send comments or objections through
> > Friday, April 1.
> >
> > Please reply to this thread if you think there's something we should
> > say as part of this charter review.
> >
> > (My understanding is that there is some concern that this work could
> > create supercookie-like features, which would be bad.)
> >
> > -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)
> >
> > ___
> > 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: Proposed W3C Charter: Hardware Security Working Group

[Richard Barnes]

Mozilla should oppose the formation of this working group.  The charter
fails to specify concrete deliverables, and many of the potential
deliverables listed have been opposed several times by browser vendors,
e.g., because hardware assets exposed to JS can be used as super-cookies.

If anything is to be done here, it should be done in a community group or
other forum until they have a story for what exactly they will be
developing and how it fits with the web security model.

On Mon, Feb 29, 2016 at 8:34 PM, L. David Baron  wrote:

> The W3C is proposing a charter for:
>
>   Hardware Security Working Group
>   https://www.w3.org/2015/hasec/2015-hasec-charter.html
>   https://lists.w3.org/Archives/Public/public-new-work/2016Feb/0009.html
>
> Mozilla has the opportunity to send comments or objections through
> Friday, April 1.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review.
>
> (My understanding is that there is some concern that this work could
> create supercookie-like features, which would be bad.)
>
> -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)
>
> ___
> 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: Talos e10s dashboard

[Chris Peterson]

On 3/1/16 9:57 AM, William Lachance wrote:

Also, mconley suggested being able to compare the results of individual
subtests. You can access this view for any given talos test by hovering
over the line in the comparison and selecting "subtests". This sometimes
give interesting data, for instance on "tps" some pages are clearly
causing more problems than others:

https://treeherder.allizom.org/perf.html#/e10s_comparesubtest?baseSignature=fe016968d213834efd424ca88680cfa7490b6c09=5c199ff7bd97284c5f3820ba908f92275620cd8b


(notice how aljaazera.net has a consistent ~450% regression!)


This looks great, Will. Good catch on the aljazeera.net problem. The 
other outliers are mail.ru (at ~410% regression) and guardian.co.uk (at 
~380% regression). We should probably file bugs for those individual 
sites. :)


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

Distribute a firefox-sdk.lib for linking a executable with icon

[Yonggang Luo]

And firefox-sdk.lib should support for application.ini directly
Or using a compiled application.ini.h obj file to link with firefox-sdk.lib
to generating a user executable.

-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Talos e10s dashboard

[William Lachance]

On 2016-02-29 1:52 AM, Chris Peterson wrote:


Will, this dashboard looks great! The current e10s release criteria
allows regressions up to 5% on the following Talos tests. Is it possible
to configure your e10s dashboard to display acceptable (<= 5%)
regressions on these particular tests using another color besides red?
Perhaps yellow to show that the e10s results are worse than non-e10s,
but not failure red?

...


After talking with cpeterson on irc, I came up with a mode for the 
dashboard which hides everything except for "regressions blocking the 
release" according to the criteria here:


https://wiki.mozilla.org/index.php?title=Electrolysis/Release_Criteria

You can see this view here:

https://treeherder.allizom.org/perf.html#/e10s?showOnlyBlockers=1

Also, mconley suggested being able to compare the results of individual 
subtests. You can access this view for any given talos test by hovering 
over the line in the comparison and selecting "subtests". This sometimes 
give interesting data, for instance on "tps" some pages are clearly 
causing more problems than others:


https://treeherder.allizom.org/perf.html#/e10s_comparesubtest?baseSignature=fe016968d213834efd424ca88680cfa7490b6c09=5c199ff7bd97284c5f3820ba908f92275620cd8b

(notice how aljaazera.net has a consistent ~450% regression!)

Will

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

planning to turn off talos posting to graphs.mozilla.org

[jmaher]

Historically talos has posted to graphs.mozilla.org.  In fact, 
graphs.mozilla.org collects the summarized data from Talos and generates alerts 
which are posted to mozilla.dev.tree-alerts.

Over the last 6 months we have been collecting the all the summarized data and 
subtest data inside of perfherder (https://treeherder.mozilla.org/perf.html#).  
Last quarter we started generating alerts from there and managing them inside a 
dashboard for perfherder: https://treeherder.mozilla.org/perf.html#/alerts.

As we now have confidence in Perfherder catching regressions from Talos, we 
would like to turn off alert generation and data uploading from Talos to 
graphserver.  If there are other tools using graph server for data, then we 
need to find those and either update them or remove them.

The one big advantage in doing this now, is that we don't have to add custom 
database entries to the graph server database anymore when we change a test or 
add a new one.

Please chime in with any concerns, I would like to make this change this week 
so we can ride the trains to Aurora.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: firefox-ui-tests are now in mozilla-central with TaskCluster support

[Matthew N.]

CC: firefox-dev

On 2016-03-01 5:17 AM, Henrik Skupin wrote:

Over the last years the formerly known Mozmill tests and now Firefox ui
tests have been located in their own repository. That meant that we
always got regressions due to changes developers have been made in
Firefox. Hunting down those regressions and fixing them was always a
time consuming job. Beside all that we were also responsible for merging
our branches accordingly to our 6 week cycle.


Hi Henrik, thanks for sharing.

Could you give an overview of what is tested by this suite and how it 
differs from mochitest-browser-chrome? It seems one difference is that 
some(?) tests run on non-en-US.


Could you also add a description to 
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Automated_testing?


Thanks,
Matthew N. (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Idle database maintenance

[Jan Varga]

Just a heads up that bug 1248550 landed on m-i today. It should fix many 
of the intermittent bugs/crashes/assertions related to idle maintenance 
and quota stuff.
Please note that in theory you can see a little slowdown in indexedDB 
mochitests if the maintenance is triggered in the background (bug  1252409).


Jan

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

firefox-ui-tests are now in mozilla-central with TaskCluster support

[Henrik Skupin]

Over the last years the formerly known Mozmill tests and now Firefox ui
tests have been located in their own repository. That meant that we
always got regressions due to changes developers have been made in
Firefox. Hunting down those regressions and fixing them was always a
time consuming job. Beside all that we were also responsible for merging
our branches accordingly to our 6 week cycle.

To finally get rid of that I was working all the last weeks to make the
following changes:

* Added mozharness scripts for executing firefox-ui-tests and enhanced
base mozharness modules to cope with various other feature requirements
we had.

* Moved our tests into mozilla-central under testing/firefox-ui/ and
updated test packaging. Backports happened down to Firefox 45.0 so that
we will benefit from the upcoming ESR release too.

* Updated mozmill-ci (which now runs our firefox-ui-tests) to use test
packages across all supported branches down to current Firefox 45.0ESR.
With that we can finally get rid of our Github repository. It turned out
to not be an easy process given that we do not only run our tests
against en-US but also a couple of other locales for nightly and release
builds. So a couple of blockers had to be fixed side-by-side in
packaging, build notifications via Mozilla Pulse etc.

* Added support for TaskCluster to run our tests once the build has been
finished. Similar to other tests this only works for linux64 debug right
now. Test results can be found on Treeherder in the Fxfn group. Keep in
mind that those are still Tier-3, so you will have to make those tests
visible. If you have to make changes to our tests and want to push to
try, simply use '-u firefox-ui-functional,firefox-ui-functional-e10s' in
the try comment (trychooser will be updated soon).

With all the above close to be done now, I'm starting to write
documentation. This will enable us to push results as Tier-2, and also
have a base set for contributors to get started hacking on our tests.

If you have questions please ask or join our #automation channel on IRC.

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

Re: "static inline" in a header file is stupid, right?

[perthomas . hille]

On Tuesday, April 3, 2012 at 10:41:37 PM UTC+2, Kyle Huey wrote:
> That's true for things at file scope, yes.  My not-very-random sample of
> MXR indicates that this is often used on static things on structs/classes,
> which has an entirely different meaning of course.
> 
> - Kyle

Static Inline makes perfectly sense in C++

Consider the following use case: (in principle I think its irrelevant if the 
function is static or not)
You have a library/DLL for which you in some case wants to link in the library 
whereas for other occasions you just want to use a small set of functions, and 
for this you use the inlined versions to avoid the hassle of having to ship 
also the DLL. 

The decision on whether to use the inlined version or the the DLL (the code 
should be the same) is taken by the compiler. If the "inline" keyword is not 
used then the implementation will be taken form the DLL wg\hen generating the 
object files, even if the implementation is present in the header file.

Now, when linking, you will get an error of the form "XYZ allready defined 
in." Because the function is implemented multiple places, firstly, in the 
DLL, the in every place where the header file containing the function is 
included.

Using "inline" will only be necessary in front of the implementation, however 
in my opinion it is a good idea to add inline also in form of the function 
definition in order to show intent, even if the keyword has no effect.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform