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
--HG--
extra : rebase_source : bc9537c701335806d4845113910b03fadadb5b77
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
--HG--
extra : rebase_source : 490f1a5186a426a41ab567e564cdbd46080262ec
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
--HG--
extra : rebase_source : 8b2eada3f9c80fe9feff880e985739a368e7b997
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
--HG--
extra : rebase_source : 720cc9d864175248508146a7f4704b4bf3f02439
extra : histedit_source : 6cc0ecbf21a571e1a41d517b67512a3452fac19a
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.
--HG--
extra : transplant_source : %C2%88%B1%DF%B2%B2.%A7%C7Ti%C8%A8%C0%CA0%15f%8D%C5
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.
--HG--
extra : transplant_source : %BBT%84%26.%AD%7B%23%1C%BC%3F%85%F9%18%A3%D8%84%EC%02%BE
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.
--HG--
extra : rebase_source : a538e3cc9d8904f52d4a0e7bad291189986e4e6d
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.
--HG--
extra : rebase_source : 450661fb1106429a455b3e9f8f66fc477c22ccef
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.
--HG--
extra : rebase_source : d61bf85407493551618ff0b7866ef15267cafd06
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.
--HG--
extra : transplant_source : %60%97%A0%8D%1D%B6%D1G%A0h%2B%11%A9%05%C1%13%25%10cc
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.
--HG--
extra : transplant_source : %84%B11%D3n%B4y%AAM%7C%B02%5E%3C%BA%B0%93%B6%FF%D5
Jan de Mooij
Phil Ringnalda
Jon Coppeard
Sebastian Hengst
Mike Conley
David Rajchenbach-Teller
Wes Kocher
Bill McCloskey
Dave Townsend
J. Ryan Stinnett
Kyle Huey
Carsten "Tomcat" Book
Sami Jaktholm
Ehsan Akhgari
Nathan Froyd
Mark Banner
Birunthan Mohanathas
Landry Breuil