There are quite a few changes in here. At a high level, all we're trying to do is to replace the old update popup with a less intrusive and more modern doorhanger (set of doorhangers) for various update success and failure conditions.
This brings the workaround for the GOOGLE_LOG(ERROR) problem when ERROR is
defined as `0` by wingdi.h in line with our workaround in the chromium sandbox
code. (http://searchfox.org/mozilla-central/rev/381a7b8f8a78b481336cfa384cb0a5536e217e4a/security/sandbox/chromium/base/logging.h#334-346)
The other patches on this bug triggered a build problem where in some situations
ERROR would be undefined when the LogLevel enum is being defined, while ERROR
was defined at a callsite. By unconditionally defining ERROR on windows and
including the LOGLEVEL_0 enum variant, we can avoid this issue and fix the
associated build bustage.
MozReview-Commit-ID: 3XFHf1FqHBr
In addition to updating gfx/webrender and gfx/webrender_traits, as well as the
Cargo.toml/Cargo.lock files and third-party rust dependencies, this updates
webrender_bindings for the following API changes:
- Update call to update_image for change in 086f912ea86d053d95e5f4eec00cae0d82ee5dba
- Update request_blob_image for new parameter added in 086f912ea86d053d95e5f4eec00cae0d82ee5dba.
- set_root_display_list got renamed to set_display_list, so update call sites.
This improves performance because we won't try to fix the permissions of the file every time the nsIHandlerService implementation wants to open it, and makes it easier to access the file path from xpcshell tests.
MozReview-Commit-ID: DZmLa92qUnZ
--HG--
extra : source : bd0fdce03cc7442079e96318d3a9b519a4d403a9
This patch also changes the 'headerURL' and 'theme_frame' properties to be of type
ExtensionURL, instead of strings. This improves validation robustness.
Alignment and tiling properties for the additional background images can be
specified in the newly introduced 'properties' section of the manifest.
MozReview-Commit-ID: BzvS3eHmDCY
--HG--
extra : rebase_source : 03560c0441bd2a6643c20a3f1fff8b905eca59ad
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : ba9f626ca2d2852f966e93401b8f8f7543615310
extra : source : 8c9117de1e7f40af42b7cbce25bc3780c032fe45