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
> delivera
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
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 o
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 l
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
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 ano
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 perfh
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 r
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 (bu
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. Bes
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 ma
11 matches
Mail list logo