This patch moves the contents of quit.js into talos-powers-content.js,
and makes it callable from content via TalosPowersContent. The code
required a few minor tweaks.
MozReview-Commit-ID: KkAbcFO0xzT
--HG--
extra : rebase_source : 4a165bc613fbc73ff8edd7bcfe2cf9cbd4a2af05
This is a new issue that gets linted with flake8 3.5.0. Basically you should
never use a blank except: statement.
This will catch all exceptions, including KeyboardInterrupt and SystemExit
(which is likely not intended). If a catch all is needed, use
`except: Exception`. If you *really* mean to also catch KeyboardInterrupt et
al, use `except: BaseException`.
Of course, being specific is often better than a catch all.
MozReview-Commit-ID: FKx80MLO4RN
--HG--
extra : rebase_source : 7c74a7d0d81f2c984b47aff3a0ee3448b791177b
Almost every chrome script uses these abbreviations. We can avoid some
boilerplate by automatically defining them on chrome contexts where we
define Components.
The var declarations for Cc and Ci in MozillaFileLogger.js are run
before enablePrivilege("UniversalXPConnect"). The latter now attempts
to automatically define Cc and Ci, but the non-configurable Cc and Ci
prevent that. Work around this by just removing the var declarations.
MozReview-Commit-ID: 6FV9ahLeqUb
--HG--
extra : rebase_source : 75a3243ea2c267fad19cc6543046dc7b130cc4c1
Bug 1383896 added this constant to testing/talos/talos/config.py:
> FAR_IN_FUTURE = 7258114800
which is used as the value for the "places.database.lastMaintenance" pref.
(7258114800 seconds after 1970 is the start of the year 2200.)
libpref stores integers prefs as int32_t and the current parser doesn't detect
overflow. So this overflows to -1331819792. (I detected this with the new prefs
parser from bug 1423840, which does detect integer overflow.) As a result the
condition testing this pref in
toolkit/components/places/PlacesCategoriesStarter.js ends up always succeeding
in tests, which is the exact opposite of what was intended. This patch changes
it to 2147483647 (the year 2038), the maximum int32_t value.
(Note: this is much the same as bug 1424030, which was fixed recently.)
MozReview-Commit-ID: AQw4b8tmE9u
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
MozReview-Commit-ID: 8uF8QbgyTcv
* Bug 1419326 - Run DAMP open/reload/close tests against a document specific to debugger
MozReview-Commit-ID: 9noPqOrsCK1
--HG--
extra : rebase_source : 511bf071d1d4664d4fd3588c5fd7cf89fbad535b
MozReview-Commit-ID: 8uF8QbgyTcv
* Bug 1419326 - Run DAMP open/reload/close tests against a document specific to debugger
MozReview-Commit-ID: 9noPqOrsCK1
--HG--
extra : rebase_source : f6adbd33bc0f74f7a84310559250c16c74d6b820
DAMP doesn't seem to require running Firefox once before running the tests.
DAMP results are about the same with/without warming up the profile.
MozReview-Commit-ID: F9ECgRfxxWY
--HG--
extra : rebase_source : 8c1ce177b12305de3ffa5bebf0e360f880d7a5c7
Also remove related code that was only used from here including
stuff related to marketplace purchases, etc.
MozReview-Commit-ID: ESX78tVQK7M
--HG--
extra : rebase_source : 56d956168f75cdc40fd3df057e41493f80733352
Doing one GC before running all test prevent having one running during the first test.
Doing another on test teardown prevent getting another during next subtests.
And finally, doing a last one after toolbox opening prevent a major GC from running during reload tests (especially "complicated" ones).
MozReview-Commit-ID: 5hkSoCqNc9m
--HG--
extra : rebase_source : 162ac5ebc0f40a9d0a2e46005d3bbd078a490694