Re: Proposed W3C Charter: Hardware Security Working Group
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
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
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&e10sSignature=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
Re: firefox-ui-tests are now in mozilla-central with TaskCluster support
They're more like end-to-end tests than browser-chrome. E.g instead of calling Gecko APIs, they'll send a mouse event to a button, send key events to a textbox, etc. So they'll theoretically perform actions closer to what a user might do. Since they're written in python, they can also do things like restart the browser within the test (for e.g testing updates). It uses a library called Firefox Puppeteer that's built on top of marionette-client: http://firefox-puppeteer.readthedocs.org/en/latest/ (which lives in testing/puppeteer despite what the docs say) Henrik can probably go into more details on what is tested. -Andrew On 01/03/16 12:18 PM, Matthew N. wrote: 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
Distribute a firefox-sdk.lib for linking a executable with icon
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
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&e10sSignature=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
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
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
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
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?
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