We want our clang bootstrap to use the GCC headers we're building with,
not whatever sysroot it happens to find on the server we're building on.
The -gcc-toolchain argument we specify when building clang will also be
picked up by llvm-config, so we need to strip it out when building the
plugin. Otherwise, we will get peculiar failures about not being able
to find C++ header files.
If the preference security.enterprise_roots.enabled is set to true, the platform will import trusted TLS certificates from the OS X keystore.
Differential Revision: https://phabricator.services.mozilla.com/D2169
--HG--
extra : moz-landing-system : lando
I mistranslated the boolean success value of the old initListBuild
method. Simplifying it to just use a promise rejection should be
equivalent and simpler, since this is only run from the update
method of WindowsJumpLists, and the call sites for that don't do
anything afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D2244
--HG--
extra : moz-landing-system : lando
For reducing virtual calls of nsIPlaintextEditor::OutputToString(),
TextEditor should have new non-virtual public method, ComputeTextValue() and
shared code between it and OutputToString() as ComputeValueInternal().
MozReview-Commit-ID: KFeovQ568bf
--HG--
extra : rebase_source : a5cfb24cefe44f7c60e649959ed49350ed00d4d6
This patch creates non-virtual method, EditorBase::GetDocumentCharsetInternal(),
for internal use of nsIEditor::GetDocumentCharacterSet() since the virtual
call method is redundant and the caller cannot be marked as const.
MozReview-Commit-ID: v6kDo2eKg3
--HG--
extra : rebase_source : 07f6dd8341cb6686835db2ee3ded479323cccca9
TextEditor::GetAndInitDocEncoder() modifies only mCachedDocumentEncoder and
mCachedDocumentEncoderType which are cache of the method to save recreation
cost of document encoder when same type document encoder is requested.
So, with marking them mutable, we can change the method to a const method.
MozReview-Commit-ID: 80W0NtQhJOR
--HG--
extra : rebase_source : 84f4b49fe3a3124c0de99b39a2141a8cee553e54
When migrating GeckoService to Oreo (Bug 1467840), the Gecko initialization was
inadvertently moved on a background thread.
This patch moves the initialization back on main thread.
MozReview-Commit-ID: Cxp7lGzPgXH
--HG--
extra : rebase_source : cf12c311dcae47cad42235587ace684788a848a1
After API 24 DownloadManager.COLUMN_LOCAL_FILENAME got deprecated and querying
for it would throw an error.
To get around this DownloadManager.COLUMN_LOCAL_URI can be used but which adds
the "file://" prefix.
MozReview-Commit-ID: CvkoFyRCLo6
--HG--
extra : rebase_source : 66b0eeecf40b1b1b9fa51860f29032e02ebe507b
It is conforming in HTML to use a div to group dt/dd elements.
Previously, we didn't create an accessible for dt/dd elements in this case.
MozReview-Commit-ID: 8GDDxU3RbLd
--HG--
extra : rebase_source : 558a67e1b21583c6fac766ee1d1a24606976177f
It was unclear why we need addressOfStringNurseryCurrentEnd but not
addressOfStringNurseryPosition. Add a comment explaining this in this
context.
--HG--
extra : rebase_source : 4fb1907c6fe133223c9d323f8062470e716df4a5
Improved the error checking in the fingerprint parsing
Changed the way the fingeerprint stores the hash algorihtm to an enum.
Extended the rust unit test for fingerprint
Fixed C++ unit tests
MozReview-Commit-ID: AS2FroZxDNv
--HG--
extra : rebase_source : be0b6d5c390ffaa90c9371436ece717e5e4e002c
Similar to lines (see previous patch), floats from next-in-flow or overflow
frames have probably not been marked dirty (as ReflowInput hasn't dealt with
them when it was constructed), so we need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first
floats from the previous column they will not be reflowed as needed.
MozReview-Commit-ID: KKrwtzeQMrI
--HG--
extra : rebase_source : ec99f380c978c6d28135490401beb0bb54c8e2b3
Lines pulled from next-in-flow or overflow frames have probably not been marked
dirty (as ReflowInput hasn't dealt with them when it was constructed), so we
need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first lines
from the previous column they will not be reflowed as needed, which causes this
bug.
MozReview-Commit-ID: 8GFO1ZWuZ1b
--HG--
extra : rebase_source : ee55a9ae7408e1f2603c1b2bc80ddcd8dbc837f0
In Bug 1188240 we disabled autoplay on Android < API version 16 because of a
vulnerability in old libstagefright, but as of Firefox 55 our minimum supported
Android version is 4.1, or API verion 16.
We've renamed the media.autoplay.enabled pref, so we can just remove the
check on media.autoplay.enabled added in bug 1188240 as it's testing for a
version of Android we no longer support anyway..
MozReview-Commit-ID: Gc8ZnlOiiMn
--HG--
extra : rebase_source : 12817b6e782331f3e4f26be0b97181418ec3287f
We're planning on enabling block autoplay on desktop by default, so in order to
be consistent across platforms, we think we should also enable it on mobile by
default.
The change here makes us allow autoplay in tabs which have had user
interaction, rather than the legacy block autoplay implementation which
"blessed" media elements which had certain functions called in a user generated
event handler.
Current plan is to enable this on Nightly only (desktop & mobile) and solicit
feedback and then decide on whether to let it ride the trains.
MozReview-Commit-ID: IkusfUOrcgO
--HG--
extra : rebase_source : 0c0a8f80d3670fffe66540f66954eaa980a42e74
We're going to enable block autoplay of HTMLMediaElements by default in Nightly,
but lots of our tests assume they are allowed to playback media without requiring
user interaction. After we've enabled block autoplay that assumption won't be valid.
So configure the prefs that control block autoplay so that we allow media to
autoplay.
This means the existing tests we have don't need to be rewritten to work when
we enable block autoplay by default.
MozReview-Commit-ID: 50yydubQjkS
--HG--
extra : rebase_source : a19e6c5b60d3b89e754be786281ca3242baa3830
We want to solicit feedback on our doorhanger implementation, so enable block
autoplay by default on Nightly only.
MozReview-Commit-ID: Kq5T8BS5Esm
--HG--
extra : rebase_source : b55a3fa34c4687a4ad4a74f38d4e46fe194aee30
Pending figuring out how we want to block autoplay of WebAudio content, we
should just not block it by default for the initial release of block autoplay,
and follow up once we've figured out how to not break the web.
MozReview-Commit-ID: ClfdrHcugLs
--HG--
extra : rebase_source : 54f61b0765f1d0ed9c754c90da9c2809a7de8676
We download the update APK into the public downloads directory and normally the
only relevant app consuming that URI should be the system package installer, but
just to be safe we only switch usage from Nougat onward, too.
This patch had already landed as part of bug 1450449, but subsequently got
overwritten during the refactoring in bug 1407046.
MozReview-Commit-ID: Ipmmlpm91zK
--HG--
extra : rebase_source : 426d98084fd26d5312e1aa5809256a5f29cd7b4d
