While working on porting the (audio-playback indicators) bug 1562990 to fission, we saw the potential to delete some methods in nsIDOMWindowUtils because they were not used anymore in our codebase except in a couple of tests files. So now, we should only mute/unmute or change the volume in the parent process. As such, interfaces are added in SpecialPowers to change media muted or volume state from content processes.
Differential Revision: https://phabricator.services.mozilla.com/D41782
--HG--
extra : moz-landing-system : lando
This condition was needed when FindInsertionPrevSibling and co didn't understand
display: contents.
Editor is pretty broken (and calls into PresShell::ContentRemoved directly, and
incorrectly, using anonymous nodes).
In this case we were taking the XBL path because of display: contents, which
means that we tried to seek to the editor anonymous node, and crash (since it's
not an explicit kid).
Editor needs to get fixed, but this is technically more correct and fixes the
crash, so we may as well take it in the interim.
Differential Revision: https://phabricator.services.mozilla.com/D42472
--HG--
extra : moz-landing-system : lando
1. As per the spec, if maxTargets is 0, return all targets.
2. Where maxTargets > 0, fix the loop condition so it doesn't incorrectly fetch one more target than requested.
Differential Revision: https://phabricator.services.mozilla.com/D42446
--HG--
extra : moz-landing-system : lando
This uses the layers.d3d11.enable-blacklist pref to allow running WebRender on WARP.
Differential Revision: https://phabricator.services.mozilla.com/D42255
--HG--
extra : moz-landing-system : lando
When we're slotted, we inherit our directionality from the slot element. But
when binding an ltr subtree into an rtl subtree, we used to bind the explicit
kids first, then the shadow root kids (which includes the slots to which
explicit kids may have been assigned).
So the explicit kids looked at the slot directionality before it was recomputed,
and thus ended up with ltr rather than rtl directionality.
Differential Revision: https://phabricator.services.mozilla.com/D42304
--HG--
extra : moz-landing-system : lando
The mozconfig in the task definition is overriden in hazard-browser.sh,
so it has effectively no effect, and hazard-browser.sh has been using
js/src/devtools/rootAnalysis/mozconfig.haz since bug 1321014.
Differential Revision: https://phabricator.services.mozilla.com/D41879
--HG--
extra : moz-landing-system : lando
__PRETTY_FUNCTION__ and __FUNCTION__ are not guaranteed to be a string
literal, and only string literals should be used as format strings. GCC
9 complains about this with -Werror=format-security.
Differential Revision: https://phabricator.services.mozilla.com/D42459
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/24
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/-yV6wb3klSA
This commit introduces a new preference option
mathml.nonzero_unitless_lengths.disabled to disable MathML nonzero unitless
values like "5" for 500%. MathML nonzero unitless are now disabled by default
but it could be easily enabled again later if we decide otherwise.
* test_bug553917.html is updated to check that these values now cause an error
message to be logged into the console rather than a deprecated warning
when nonzero unitless lengths are disabled.
Additionally, the test checking invalid double dots "2..0" is updated not
to use unitless syntax.
* The old test 355548-3.xml checks support for mathsize names and also uses
several features that are going to be deprecated. So it is just run with
the proper preference adjustment.
* mfrac-linethickness-2.xhtml and number-size-1.xhtml check support for
unitless lengths so they are now run with that support enabled.
* WPT tests frac-linethickness-001.html and lengths-1.html are executed with
the some MathML features disabled in order to make them pass.
We get more assertion passing for the "Legacy numbers" test of
lengths-2.html ; however there are still some issues to address
(see bug 1574751).
Differential Revision: https://phabricator.services.mozilla.com/D42427
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/7
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/kyB34PjYXek
This commit introduces a new preference option
mathml.mathsize_names.disabled to disable mathsize keyword values. For
now, these are only disabled in Nightly builds.
* test_bug553917.html is updated to check that these values now cause an
error message to be logged into the console when mathsize names are used
and the feature disabled.
* The old test 355548-3.xml checks support for mathsize names and also uses
several features that are going to be deprecated. So it is just run with
the proper preference adjustment.
* mathml/relations/css-styling/mathsize-attribute-legacy-values.html passes
after this change so the test is run with the mathsize names disabled too
and the failure expectation is removed.
* mathml/relations/css-styling/mathsize-attribute-css-keywords.html is added
to check that CSS keywords won't be supported when we switch to using the
CSS parser in the future. This test passes now when the "small" keyword
is not accepted so it is run with the mathsize names disabled too.
Differential Revision: https://phabricator.services.mozilla.com/D42426
--HG--
extra : moz-landing-system : lando
These two bugs (bug 1572738 and bug 1572451) are stylo regressions.
When font-family changes, we try to recompute the font-size with a length /
percentage combinations in case the generic family changes, so the user
preferences are kept.
When calc() is involved, we clamp to non-negative too early, via
NonNegativeLength::scale_by.
I think we should generally dump this "try to track font-size across calc()"
thingie, as as various comments note it is not quite perfect, and it's not clear
how it should work in presence of min()/max().
This patch fixes the issue and simplifies code a bit, I may consider removing
this altogether in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D41776
--HG--
extra : moz-landing-system : lando
The `MockSecurityInfo` instances in the patched devtools tests are not actually
being used as `nsITransportSecurityInfo` instances; while `QueryInterface`
methods were generated for the them, these were never called. Additionally, the
methods they are being passed to are not XPCOM-defined and therefore do not
strictly require `nsITransportSecurityInfo`.
In addition `NetworkHelper#parseSecurityInfo` now requires its `securityInfo`
to be `QueryInterface`d to a `nsITransportSecurityInfo` before calling the
function (except in the case of `MockSecurityInfo`, which is structurally
similar).
Differential Revision: https://phabricator.services.mozilla.com/D40521
--HG--
extra : moz-landing-system : lando
updateLayer expects some objects to be non-null which are only initialized when the pref is set.
But in builds that were compiled with the 10.14 SDK, all NSViews are layer-backed by default, so
wantspdateLayer gets called, and returning YES from that unconditionally will cause updateLayer
to be called.
Differential Revision: https://phabricator.services.mozilla.com/D42333
--HG--
extra : amend_source : a7a1f7ecba9418e3bf5464bca90ba655002bc637
