This adds the pref "security.pki.distrust_ca_policy" which, if set to 1,
enforces the graduated distrust from Bug 1409257, and if set to 0 (as it is in
this patch) disables that distrust.
This pref is intended to outlast the Symantec distrust, and instead be able to
extend to enable/disable future root policy actions. It would need its own
tests for that, in the future.
MozReview-Commit-ID: BAZfkapysfX
--HG--
extra : rebase_source : 02b00aa486e9f8efb81b32d38d80db5cae86bc6e
We'll stop dispatching "keypress" event for non-printable keys and key
combinations in the default event group of web content. Therefore,
onbording.js needs to stop handling some keys with "keypress" event listener.
This patch makes add a "keydown" event listener, handleKeydown(), and make it
handle only non-printable keys. Note that we'll keep dispatching "keypress"
event for " " and "Enter". So, we can keep handling them in "keypress"
event listener.
MozReview-Commit-ID: 1jFIv9N03fa
--HG--
extra : rebase_source : 8acabac7ae5c06b527a9fad0fb0fb7b3a2cc5a61
In order to stay consistent with the AutoTimer api, allowed non-templates uses or AutoCounter.
MozReview-Commit-ID: 9qnAeQTIY9T
--HG--
extra : rebase_source : 8c95992e2d291d628721febbc7b641b91c850288
Moved the runtime Telemetry::AutoTimer implementation to the Telemetry public API.
MozReview-Commit-ID: KNT6toDQUtR
--HG--
extra : rebase_source : 8d40759f616511f0a3a19d42c8105e6278bf7e2a
The file copies and renames make this patch look a bit confusing. Here's what
happens:
ThreadInfo.h:
Most of the code gets moved into RegisteredThread.h and ProfiledThreadData.h,
but a small piece remains in ThreadInfo.h.
ThreadInfo.cpp:
Gets split into RegisteredThread.cpp and ProfiledThreadData.cpp.
ThreadInfo.cpp itself goes away.
In the mercurial changeset, I've marked ThreadInfo.h as being copied to both
RegisteredThread.h and to ProfiledThreadData.h, and ThreadInfo.cpp as being
copied to RegisteredThread.cpp and as being renamed to ProfiledThreadData.cpp.
MozReview-Commit-ID: 1j1imAv9cTd
--HG--
rename : tools/profiler/core/ThreadInfo.cpp => tools/profiler/core/ProfiledThreadData.cpp
rename : tools/profiler/core/ThreadInfo.h => tools/profiler/core/ProfiledThreadData.h
rename : tools/profiler/core/ThreadInfo.cpp => tools/profiler/core/RegisteredThread.cpp
rename : tools/profiler/core/ThreadInfo.h => tools/profiler/core/RegisteredThread.h
extra : rebase_source : 91310691d5e46246ec03305511c1b86ab458b0b9
This test will cause timeout once we have a microtask checkpoint at the end of
a callback (bug 1193394). Fortunately the test is for the old debugger UI that
we don't ship anymore, so we can just skip it.
MozReview-Commit-ID: AjB1YSNyToD
--HG--
extra : rebase_source : 382dd2533a78cafa41ab4eeea5475d97f65ff6b9
The overlay elements with children of editMenuOverlay.xul are moved into
include files (editMenuCommands.inc.xul and editMenuKeys.inc.xul). For
the other single elements in the overlay, the attributes are inlined
wherever they are used.
MozReview-Commit-ID: 792cuzUvQxT
--HG--
extra : rebase_source : 58e4c05bde16cee873d37c6198de102d048499c2
Without any flex, the checkboxes in the Privacy section of about:preferences
refused to wrap their text and caused the page width to expand to accommodate
them, which made the search box and other elements move around while performing
searches as the page width changed.
Adding flex means the checkbox wraps text to the next line when the label is
longer than the width can accommodate.
MozReview-Commit-ID: HtJ3f3KrO3X
--HG--
extra : rebase_source : 37c25c9f829632a0304eb74734174d8565050eeb
Importing this object is unnecessary after the updates to the WebIDL console from Bug 1425574
and the follow-ups blocking Bug 1430810. There are still callers that access Console.jsm
to create custom ConsoleAPI objects, but those will be handled separately.
MozReview-Commit-ID: 9ojFxtkpPId
--HG--
extra : rebase_source : 971bf99f709b8d2afe300f3693665724f747aa5e
As of Bug 1425463 it's available in all contexts (including JSM). The following
patche is going to remove imports to Console.jsm, so prepare for this by allowing
it to be used as a global in eslint.
MozReview-Commit-ID: 3gCIspnlVgB
--HG--
extra : rebase_source : 6da75d42d7d937b628ef1d9c0d4e349fd76eda36
Also, get rid of a gratuitous use of a trinary operator in
nsXPCWrappedJSClass::CallMethod, clean up the style a little, and mark
an unimplemented ctor as deleted.
MozReview-Commit-ID: Kp64sMxyRWc
--HG--
extra : rebase_source : e6082003d3759234cd5f4630b5560b14930c0a88
Also, clean up the style a little and mark an unimplemented ctor as
deleted.
MozReview-Commit-ID: JqmveE6qWFa
--HG--
extra : rebase_source : 62c8249de1f52686b4dd5d2a043261d2618d7433
Also, remove a few unused things.
Removing the include of xpt_arena.h from xpt_struct.h required that I
added it to two other files.
MozReview-Commit-ID: 4bMDRYt0Zxc
--HG--
extra : rebase_source : 91548b62dbf4b92bf918d196067e6fabb9a72302
This makes the file 2-space indented, gets rid of padding between
types and members, moves the * to the left, fixes the mode line,
license and include guards, and fixes up the first line of some of the
multiline comments. I also reordered the XPT_ANN macros to be more
consistent.
I left the padding alone for the enum-like bit flag values, as I think
it makes sense to line those up.
MozReview-Commit-ID: 877aP5eGIFm
--HG--
extra : rebase_source : 6d47ce05b47248c285597454af528ca1ae2cc830
For FF59, we disabled WebVR for macOS before allowing it to ride the trains to release. Softvision was unable to verify for QA due to challenges getting a working hardware configuration for macOS VR at SoftVision.
We have since gained approval from the Firefox Release Team to re-enable WebVR for macOS in release for FF60.
Essentially, we need to reverse the changes in bug 1426500 and uplift to FF59/Beta before the next cycle.
--HG--
extra : rebase_source : 1b0c68b130f869f0e71cf2d93db92bb78dddc79b
Right now you could still set preffed-off properties from CSSStyleDeclaration.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3d8363cd87cd9e94fa6ce5e1ba14123e0514a7ef
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 17a3a4ba12d73f86565e7a0fd1f95b734cb9ec40
This should help the ongoing disk usage problems.
Source-Repo: https://github.com/servo/servo
Source-Revision: 068c1eb9fbff43bcf089c7c27101c72ef205b0c8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4fce578abe5343310c632256c10e28fe53709084
This is the only use of this type.
Source-Repo: https://github.com/servo/servo
Source-Revision: 030509e66b9d3432c112bb5639f446535749963e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4c8d312495ec20ce733a86f771c08ac6884b6c59
This is part of a patch that was reviewed by nox in #20081, but which I reverted because that approach didn't quite work.
I think I have something that works now, but I'm waiting for a Geckotry. Landing this should be worth it in the meantime though.
Source-Repo: https://github.com/servo/servo
Source-Revision: b9e16e54aae8daa3249e2a8b4483ce302d817f56
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 34bea2135c443c55683158afa42b91f6036101f0
There are a lot of choices and moving pieces in this commit. I elected
to include the mechanics and the target use case in the same commit so
that readers can compare and contrast the implementation and final
expression in one review window.
- Initially, I wanted to make the {AB_CD} substitutions in
LOCALIZED_FILES and not in LOCALIZED_GENERATED_FILES. However, I ran
into conceptual blockers doing this. Fundamentally, LOCALIZED_FILES
is FINAL_TARGET_FILES, and my use case should _not_ be putting files
anywhere near dist/bin. In addition, LOCALIZED_FILES
(FINAL_TARGET_FILES) is handled using manifests, which would need to
grow locale-aware functionality to handle this. That's not desirable.
In addition, if we use manifests, then we lose the powerful locality
of |mach build mobile/android{/base}| re-generating changed
locale-dependent resources. This is similar to how the build system
plumbs dist/idl manifest processing throughout the build: we're
repairing local workflows after moving work into a global process.
For these reasons, this doesn't support {AB_CD} in LOCALIZED_FILES.
- There is even another layer of complexity! There are two axes
involved with these files: AB_CD controls localization and the Make
target controls destination. For the record, it is:
regular builds - AB_CD unset
multi-locale builds - AB_CD set
single-locale repacks - AB_CD set
For the record, the existing logic (before any changes) is:
regular builds - Make target is `libs` in mobile/android/base/locales
multi-locale builds - Make target is `chrome-%` in mobile/android/base/locales
single-locale repacks - Make target is `libs` in mobile/android/base/locales
This commit adds targets for both destinations, and uses Make
chrome-%:: and libs:: magic to control what is invoked in the various
situations. Tricky!
- I added MERGE_RELATIVE_FILES in order to be able to follow-up this
patch with more patches that will get rid of
m/a/base/locales/{moz.build,Makefile.in} altogether, and fold this work
into m/a/base. As it stands, we're already reaching from
m/a/base/locales all the way out to
mobile/locales/.../region.properties, so the existing code doesn't
follow the layout expected between mozilla-central and
l10n-central/$(AB_CD). But that'll impedance will get worse as we
improve the build system dependencies, not better, so we should grow
support for localized resources that aren't exactly as expected.
- I chose to follow Python's syntax for string substitutions. I
would have preferred to mark files that should be localized with a
leading '%'... but I took that for filesystem absolute paths in
moz.build files already. I also considered @AB_CD@ to echo the
preprocessor, but didn't want to open the door to an expecation that
_all_ preprocessor DEFINEs will work in the way {AB_CD} does.
- The generate_*py script changes required a bit of a hack to "turn
off" locale dependent resources. This would have been nicer if we had
marked localized resources with '%'... but we didn't. See the
--fallback flag. The real reason this is needed is that we're doing
work which is more like the work of compare-locales (merging
locale-dependent resources) at build-time rather than repack time. I
don't know why that's the case -- probably when we (I) implemented it,
compare-locales and the whole l10n process was entirely opaque. It's
not worth changing it now, so we use this --fallback flag approach.
- I didn't get to tup support. This should gently fail without
breaking tup builds: any {AB_CD} substitutions just won't be
expanded. I haven't a clue how this should work in tup in the future
(or, more generally, how to make any sense of repacks without
declaring the full set of expected locales at configure time.)
- strings.xml can't be a LOCALIZED_PP_FILES, since we need to
customize the output location based on AB_rCD, and since we need a
little more flexibility than PP_FILES gives for our inputs.
MozReview-Commit-ID: MyfIkNSEzt
--HG--
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/en-US/localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/en-US/localized-input
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/foo-data => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/foo-data
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/generate-foo.py => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/generate-foo.py
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/en-US/localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/inner/locales/en-US/localized-input
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/moz.build => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/moz.build
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/non-localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/non-localized-input
extra : rebase_source : 816b6f220758f2bb3bdd3ec81a2cb02269c6de5b
I wanted to lift this next to the definition of AB_CD, but that
doesn't allow to use it in a backend.mk file, due to the order in
which Makefile, config.mk, rules.mk, and backend.mk are processed.
Therefore, I've put it in a tiny include file, so that it can be used
by a Makefile and a backend.mk file.
This allows the `RecursiveMake` backend to owning defining AB_rCD in
backend.mk files, while not requiring consumers to arrange for AB_rCD
in a sibling Makefile.in file.
Other build backends will need to arrange for AB_rCD themselves: see
following commits.
MozReview-Commit-ID: I7GIzRbCCtf
--HG--
extra : rebase_source : 3277fedb43bc3d8007287c223554a085dae2f198
extra : source : 854c0f43a1f74b4e22aa7638b407580240c90dd5