This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
browser_Addons_sample is used by the browser_AddonWatcher.js test to make sure
we can properly detect when an add-on consumes a bunch of CPU or does a lot of
CPOW traffic.
There's a race condition in the add-on where what is supposed to be a CPOW
might not always be a CPOW, so when we try to cause a bunch of CPOW
traffic, we don't get the expected performance warnings.
This makes sure that when we try to simulate CPOW usage, we do it
with an actual CPOW.
Additionally, this commit also includes the unpacked source of the
add-on, which before wasn't in the tree. I've also taken the liberty
of bumping the add-on version and signing it.
MozReview-Commit-ID: GICLYpi8Kon
Although I haven't been able to pinpoint why, it looks like
nsPerformanceStatsService::Dispose() may be called twice, which in
turn causes crashes. This patch makes sure that calling the method
twice is idempotent.
Also, just in case this was due to a typo in
AddObserver/RemoveObserver, this patch replaces the literal strings
used in both with constants.
MozReview-Commit-ID: 8fXO20r5xvO
Although I haven't been able to pinpoint why, it looks like
nsPerformanceStatsService::Dispose() may be called twice, which in
turn causes crashes. This patch makes sure that calling the method
twice is idempotent.
Also, just in case this was due to a typo in
AddObserver/RemoveObserver, this patch replaces the literal strings
used in both with constants.
MozReview-Commit-ID: 8fXO20r5xvO
Most of this is fixing functions that in some cases return a value but then
can also run to completion without returning anything. ESLint 2 catches this
where previous versions didn't. Unless there was an obvious other choice I just
made these functions return undefined at the end which is effectively what
already happens.
MozReview-Commit-ID: KHYdAkRvhVr
The current API of AddonWatcher only supports a single callback. That's pretty unfriendly to testing, debugging, add-ons, etc.
This patch replaces the mechanism with a notification through the nsIObserverService.
During shutdown, we may find ourselves attempting to release and shutdown a probe while the PerformanceStats service is already shutdown. In this case, since the probe is already shutdown, we can simply ignore the error.
This patch (currently WIP) alters the way we determine whether jank is user-visible or not.
Instead of measuring the total time spent doing JS, we now use an
indicator provided by the vsync driver: how long it takes to deliver
the signal from the vsync timer to the main thread. This lets us find
out more accurately if there is user-visible jank. In the future, this
will also let us add an observer to find out whether the process
itself is janky, regardless of JS.
To decrease the number of apparent false positives, we classify jank
alerts as visible or invisible. We use the following heuristic:
- if the process is currently animating something, any jank alert is visible;
- if the process has just handled a user input, any jank alert is visible;
- if some user input is handled during the current iteration, any jank alert is visible;
- otherwise, jank alerts are not visible.
Showing alerts more than once is annoying for the user and basically
useless. We therefore change a bit our strategy:
- if an add-on has behaved correctly for the last 5 minutes, reset our counter of offences;
- don't display alerts for an add-on more than once per 6 hours.
The only exception is if the add-on freezes the browser (i.e. causes
it to stop for more than 5 seconds at a time), in which case we
display the alert regardless of past offences, up to once per 10
minutes.
Since no one is holding a reference to the burnCPOWInSandbox function
in the child process, it might get GC'd during the test. Binding it to
the global object should keep the function alive long enough for the
test to call it via CPOW.
This patch introduces a new API to the nsPerformanceStatsService to register observers for slow performance. This API has several advantages:
- as it doesn't require polling, it also doesn't need to wake up the parent process every 15 seconds for the AddonWatcher;
- as it doesn't require polling, it doesn't need to wake up the child processes every time we wish to obtain data on slow performance;
- as it provides immediate data on performance alerts, it makes it possible to get rid of the complex and expensive post-processing performed by JS to merge data from all processes and attempt to extract performance alerts.
The old API is still available.
