This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
This is a temporary workaround to avoid the intermittent orange. We still need to track down what the
underlying cause of the difference in timings between compartments and processes really is.
MozReview-Commit-ID: GmT67UDuTqN
This removes all the code for add-on performance watching from the
perfmonitoring component. This should mean that for add-on
compartments, we no longer trigger jank or CPOW monitoring in the JS
engine. This should result in minor performance improvements. As a
result, about:performance no longer reports on add-on performance
(but still reports on web page performance).
It also removes the AddonWatchers.jsm module and the related Nightly-
only UI (disabled in the parent commit) and strings. This UI wasn't
ready for release, there wasn't sufficient data it was creating
value for users, and there was some evidence that it didn't always
correctly identify the cause of performance issues, thus potentially
leading to user confusion or annoyance. Removing it therefore seemed
the right thing to do.
MozReview-Commit-ID: LsRwuaUtq6L
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
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.
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.