On 01/16/2014 07:41 PM, Vivien Nicolas wrote:
On 15/01/2014 20:48, Andrew Sutherland wrote:
However, the simplest/most pragmatic thing to do initially is probably
just to use the existing linux perf tool to generate logs of what's
happening during the test runs using perf schedule and when we
Le 15/01/2014 18:24, Fabrice Desré a écrit :
On 01/15/2014 09:09 AM, Julien Wajsberg wrote:
CSS errors are another story, especially when we use CSS properties that
are prefixed/unprefixed and we try that the apps somehow load in other
browsers. But we definitely have some that needs to be
I am (this is exactly bug 606574), but my understanding was that it does
not suppor Gonk yet?
If it does then this is less work :)
On 17/01/2014 04:05, Andrew Halberstadt wrote:
Vivien, are you aware of the existing event loop monitor built into
Gecko? You just need to set
As I said in one other post to this thread. We will be able to cherry
pick the warning we care about directly in Gaia.
You won't see them anymore in logcat too.
On 17/01/2014 12:05, Julien Wajsberg wrote:
Le 15/01/2014 18:24, Fabrice Desré a écrit :
On 01/15/2014 09:09 AM, Julien Wajsberg
, 2014 9:24:22 AM
Subject: Re: [b2g] Proposal: Cracking down on arbitrary Javascript
exceptions
On 01/15/2014 09:09 AM, Julien Wajsberg wrote:
CSS errors are another story, especially when we use CSS properties
that
are prefixed/unprefixed and we try that the apps somehow load in
other
browsers
, mozilla-dev-...@lists.mozilla.org
Sent: Wednesday, January 15, 2014 9:24:22 AM
Subject: Re: [b2g] Proposal: Cracking down on arbitrary Javascript
exceptions
On 01/15/2014 09:09 AM, Julien Wajsberg wrote:
CSS errors are another story, especially when we use CSS properties
that
are prefixed/unprefixed
On 17/01/2014 13:11, David Scravaglieri wrote:
Le 17/01/14 13:00, Vivien Nicolas a écrit :
What's Andrew nickname on IRC? I guess we can just spoke and figure
that out.
ahal
Merki
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
On 15/01/2014 20:48, Andrew Sutherland wrote:
However, the simplest/most pragmatic thing to do initially is probably
just to use the existing linux perf tool to generate logs of what's
happening during the test runs using perf schedule and when we see a
failure due to event loop sadness, we
Wajsberg jwajsb...@mozilla.com, Hubert Figuière
h...@mozilla.com, mozilla-dev-...@lists.mozilla.org
Sent: Wednesday, January 15, 2014 9:24:22 AM
Subject: Re: [b2g] Proposal: Cracking down on arbitrary Javascript
exceptions
On 01/15/2014 09:09 AM, Julien Wajsberg wrote:
CSS errors are another
Message -
From: Fabrice Desré fabr...@mozilla.com
To: Julien Wajsberg jwajsb...@mozilla.com, Hubert Figuière
h...@mozilla.com, mozilla-dev-...@lists.mozilla.org
Sent: Wednesday, January 15, 2014 9:24:22 AM
Subject: Re: [b2g] Proposal: Cracking down on arbitrary Javascript
exceptions
On 01/15/2014
Vivien, are you aware of the existing event loop monitor built into
Gecko? You just need to set MOZ_INSTRUMENT_EVENT_LOOP=1.
See https://blog.mozilla.org/ted/2011/06/27/measuring-ui-responsiveness/
and
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/EventTracer.cpp#5
for more
On 01/15/2014 09:09 AM, Julien Wajsberg wrote:
CSS errors are another story, especially when we use CSS properties that
are prefixed/unprefixed and we try that the apps somehow load in other
browsers. But we definitely have some that needs to be fixed.
That doesn't apply to certified apps
Wajsberg jwajsb...@mozilla.com, Hubert Figuière
h...@mozilla.com, mozilla-dev-...@lists.mozilla.org
Sent: Wednesday, January 15, 2014 9:24:22 AM
Subject: Re: [b2g] Proposal: Cracking down on arbitrary Javascript exceptions
On 01/15/2014 09:09 AM, Julien Wajsberg wrote:
CSS errors are another
: [b2g] Proposal: Cracking down on arbitrary Javascript
exceptions
On 01/15/2014 09:09 AM, Julien Wajsberg wrote:
CSS errors are another story, especially when we use CSS properties that
are prefixed/unprefixed and we try that the apps somehow load in other
browsers. But we definitely have some
On 01/15/2014 09:54 AM, Vivien Nicolas wrote:
I also want to expose event loop lags if possible and make them a test
failure.
That looks very dependent on the performance of the test runner. How do
we take that into account?
Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation
On 15/01/2014 18:59, Fabrice Desré wrote:
On 01/15/2014 09:54 AM, Vivien Nicolas wrote:
I also want to expose event loop lags if possible and make them a test
failure.
That looks very dependent on the performance of the test runner. How do
we take that into account?
Performance should vary
On 01/15/2014 12:59 PM, Fabrice Desré wrote:
That looks very dependent on the performance of the test runner. How do
we take that into account?
We could use operating system facilities to detect and mark (or even
abort) test runs where the test runner is not meeting certain
performance
-dev-...@lists.mozilla.org
Sent: Wednesday, January 15, 2014 9:24:22 AM
Subject: Re: [b2g] Proposal: Cracking down on arbitrary Javascript
exceptions
On 01/15/2014 09:09 AM, Julien Wajsberg wrote:
CSS errors are another story, especially when we use CSS properties
that
are prefixed
One wrinkle I ran into while removing some CSS warnings in email for bug
96004, there are two “will-change” uses that show up as warnings. I believe
this is an experimental property used in some builds/config settings of
Gecko, and I think we want to keep those in.
You probably mean bug 960094.
CSS errors are another story, especially when we use CSS properties that
are prefixed/unprefixed and we try that the apps somehow load in other
browsers. But we definitely have some that needs to be fixed.
Bug 959945 is an example of a seemingly-innocuous JavaScript Warning
CSS issue in Gaia
On 16/01/14 02:14 AM, Vivien Nicolas wrote:
On 15/01/2014 18:59, Fabrice Desré wrote:
On 01/15/2014 09:54 AM, Vivien Nicolas wrote:
I also want to expose event loop lags if possible and make them a test
failure.
That looks very dependent on the performance of the test runner. How do
we take
The feedback to this proposal is overwhelmingly positive, so we'll try
and get something stood up, possibly on a project branch or possibly
just printing warnings to the summary instead of causing an outright job
failure for now. We'll need to fix all of the currently existing
exceptions
On 01/14/2014 08:11 PM, Andrew Halberstadt wrote:
1) Is this a good idea?
yes.
2) Should we only look at startup failures or for example all failures
throughout an entire mochitest run?
all of them!
3) If a test run modifies the profile, does that disqualify it from
having the check
On 15/01/14 12:14 PM, Fabrice Desré wrote:
I can't see any reason to disqualification, but maybe I'm missing
something. Why are you asking that question?
For example, mochitest replaces the homescreen app using the
homescreenURL pref. This might break certain assumptions and cause
errors.
I think yes, yes and yes! Although for 2) I think we can break it down
into a priority of startup where modules are initialised, these seem to
point to configuration issues/regressions like the ril ones that Kevin
has addressed lately.
The only preference I have is that I would like them to
On 14/01/14 11:11 PM, Andrew Halberstadt wrote:
Many of you may have noticed that when using b2g desktop or the
emulator, the logcat is riddled with Javascript exceptions from various
apps and parts of the platform. For example, search [1] for JavaScript
error. While many of these errors may
26 matches
Mail list logo
