Changed error message to unlocalized in the callback and in the promise rejection in case an error occurs in audio decoding.
Also deleted localized strings and NoAudio bacause it is not used.
Differential Revision: https://phabricator.services.mozilla.com/D81337
The only common failure case that's not being warned about now is when the user
rejected the prompt, which I think is expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D79597
The only common failure case that's not being warned about now is when the user
rejected the prompt, which I think is expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D79597
The only common failure case that's not being warned about now is when the user
rejected the prompt, which I think is expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D79597
The only common failure case that's not being warned about now is when the user
rejected the prompt, which I think is expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D79597
This patch adds the boolean pref mathml.stixgeneral_operator_stretching.disabled, which defaults to true iff nightly.
When the pref is true, stretched operators won’t be rendered with STIXGeneral, because we only use OpenType MATH tables (in fonts that have them) or the generic Unicode table.
When the pref is false, we continue to support STIXGeneral for stretched operators, but warn the author in devtools and bump the use counter (up to once per page). This only happens when a stretched operator actually uses STIXGeneral: not when we successfully render the operator with some other font earlier in the font-family stack, and not when STIXGeneral isn’t installed.
Differential Revision: https://phabricator.services.mozilla.com/D73833
Labels are often used as primary click targets for related inputs. If
they are styled to certain bounds, but contain overflowing text for a11y
with a color of "transparent", the synthesized click will happen outside
the bounds of the label.
If we skip text leafs with "color: transparent", we will skip labels
altogether. Instead, lets land on labels when traversing, and ignore
its subtree.
Differential Revision: https://phabricator.services.mozilla.com/D77898
Labels are often used as primary click targets for related inputs. If
they are styled to certain bounds, but contain overflowing text for a11y
with a color of "transparent", the synthesized click will happen outside
the bounds of the label.
If we skip text leafs with "color: transparent", we will skip labels
altogether. Instead, lets land on labels when traversing, and ignore
its subtree.
Differential Revision: https://phabricator.services.mozilla.com/D77898
This combines the two places where an error was generated for this into one and adds localiation for the message. The message is improved as requested in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D79862
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
Feeding a media element with the captured stream from the same media element does not make sense. Currently the spec does not mention anything about it. I'll clarify the case in the spec. In the meantime, when a cycle is detected, the setting of the `srcObject` is ignored and a warning is produced in the console.
Differential Revision: https://phabricator.services.mozilla.com/D76821
This removes processing of HTTP Public Key Pinning headers, remotely modifying
pinning information, and using cached pinning information, all of which was
already disabled in bug 1412438. Static pins that ship with the browser are
still enforced.
Differential Revision: https://phabricator.services.mozilla.com/D73352
It's not like we're going to change behavior here anytime soon anymore
(other than removing XUL usage), and the helpfulness of the warning has
probably decreased with time.
But maybe I'm missing a reason why it should be kept around?
Differential Revision: https://phabricator.services.mozilla.com/D73544
- Add new CSS Error
- Add new test case for error
- Ensure that test cases use `replace()` and `replaceSync()`
Differential Revision: https://phabricator.services.mozilla.com/D69423
--HG--
extra : moz-landing-system : lando
Pages apparently do this to try to open to native apps, and that on Firefox
causes an error page to be shown if the app is not installed, which is pretty
bad.
Differential Revision: https://phabricator.services.mozilla.com/D68471
--HG--
extra : moz-landing-system : lando
Pages apparently do this to try to open to native apps, and that on Firefox
causes an error page to be shown if the app is not installed, which is pretty
bad.
Differential Revision: https://phabricator.services.mozilla.com/D68471
--HG--
extra : moz-landing-system : lando
As child-src is no longer deprecated in the CSP level 3 spec, this removes the
console warning, since it's valid to use it as a fallback for frame-src and
worker-src.
Differential Revision: https://phabricator.services.mozilla.com/D62034
--HG--
extra : moz-landing-system : lando
Mark the html:mark element to the new ROLE_MARK, which currently maps the same as role_text, and the xml-role of "mark", make sure we expose the roleDescription on Mac, and adjust the test so it tests that the attributes don't pick up any unexpected color for this particular element. So, the background attribute is empty when there is no unexpected, non-default background color.
Differential Revision: https://phabricator.services.mozilla.com/D52989
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
I use `warningFlag` instead of `infoFlag` because even if the principal
writing-mode propagation is written in the spec, its effect might
surprise the developers.
Differential Revision: https://phabricator.services.mozilla.com/D48774
--HG--
extra : moz-landing-system : lando
Web Share base implementation just of DOM stuff - working together with @saschanaz.
@Baku, we would greatly appreciate your review.
-Nika, as she is traveling.
Differential Revision: https://phabricator.services.mozilla.com/D44598
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/70NFnet82cU
This commit introduces a new mathml.xlink.disabled option to disable support
for XLink attributes on MathML elements together with a use counter and
deprecation warning when support is enabled. For now, support is only disabled
in Nightly.
In the past, we relied on custom MathML deprecation warnings but those are
removed here. Corresponding tests for these legacy warning messages are
also removed from test_bug553917.html.
link-1.xhtml is run with XLink support enabled (since it checks xlink:href)
while browser_contentAltClick.js and browser_contentAreaClick.js are updated
to instead check MathML links (i.e. href instead of xlink:href).
Differential Revision: https://phabricator.services.mozilla.com/D43332
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/vwAkuZIEhnY
* Introduce a new preference option to disable menclose's "radical" notation.
* Disable the notation in Nightly and when running WPT tests.
* Enable the notation in other channels together with a counter and
deprecation warning.
* Update WPT test legacy-menclose-radical-notation.html
- Fix test: "radical" should be equivalent to "", which is not the same as
the default value "longdiv".
See https://github.com/mathml-refresh/mathml/issues/144
- Add a test "box radical" which should be equivalent to "box".
- Remove failure expectation.
* Enable the radical notation for MathML reftests testing it.
Differential Revision: https://phabricator.services.mozilla.com/D46721
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/vwAkuZIEhnY
* Introduce a new preference option to disable menclose's "radical" notation.
* Disable the notation in Nightly and when running WPT tests.
* Enable the notation in other channels together with a counter and
deprecation warning.
* Update WPT test legacy-menclose-radical-notation.html
- Fix test: "radical" should be equivalent to "", which is not the same as
the default value "longdiv".
See https://github.com/mathml-refresh/mathml/issues/144
- Add a test "box radical" which should be equivalent to "box".
- Remove failure expectation.
* Enable the radical notation for MathML reftests testing it.
Differential Revision: https://phabricator.services.mozilla.com/D46721
--HG--
extra : moz-landing-system : lando
Intent to unship: https://groups.google.com/forum/#!topic/mozilla.dev.platform/JnJVGTmIwPE
- Introduce a new preference option mathml.deprecated_alignment_attributes.disabled()
to disable alignment attributes for mfrac/munder/mover/munderover elements.
- Disable the attributes in Nightly and when running WPT tests.
- Enable the attributes in other channels but add a counter and deprecation warning.
- Remove failure expectation for WPT test frac-numalign-denomalign-001.html for mfrac
- Add new WPT test for underover-legacy-align-attribute-001.html for munder/mover/munderover
- Enable the attributes for MathML reftests checking these attributes.
- Disable numalign/denomalign test for Mochitest test_bug975681.html when the attributes
are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D46712
--HG--
extra : moz-landing-system : lando
Now that we count them, I think we should do this.
This property is pretty painful for various reasons:
* It's a pretty awkward non-standard property.
* Has a pretty short name, so people use it instead of the standard
alternatives.
* We cannot really even implement it easily anyhow, without breaking a whole
bunch of stuff, because pages do things like:
```
myelement {
zoom: 0.5;
-moz-transform: scale(0.5);
transform-origin: 0 0;
}
```
For now this is only recorded when CSS use counters are enabled (Nightly for
now), but I want to change it once bug 1578661 is in central.
The hope is that this warning slightly raises awareness of this property not
being standard. You get a CSS parsing error in the console, but those are
usually too noisy and disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D46430
--HG--
extra : moz-landing-system : lando
We log to MOZ_LOG, report an error to the console, send telemetry, and in debug builds - crash
Differential Revision: https://phabricator.services.mozilla.com/D45055
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/70NFnet82cU
This commit introduces a new mathml.xlink.disabled option to disable support
for XLink attributes on MathML elements together with a use counter and
deprecation warning when support is enabled. For now, support is only disabled
in Nighly.
In the past, we relied on custom MathML deprecation warnings but those are
removed here. Corresponding tests for these legacy warning messages are
also removed from test_bug553917.html.
link-1.xhtml is run with XLink support enabled (since it check xlink:href)
while browser_contentAltClick.js is updated to check whether XLink has any
effect on MathML, depending on whether the option is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D43332
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/5#issuecomment-475506856
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/kl5c87mBlO0
This patch introduces a new preference
mathml.deprecated_style_attributes.disabled in order to disable legacy support
for attributes background, color, fontfamily, fontsize, fontstyle and
fontweight. Note that xlink:href will be handled separately in bug 1575870.
* A new counter and deprecation message is introduced for these attributes.
In nsMathMLElement, the old WarnDeprecated calls are replaced with a single
call to WarnOnceAbout for the deprecate attributes. Notice that for some
reason, the color attribute used to send warning in both ParseAttribute and
MapMathMLAttributesInto.
* sMtableStyles is removed and replaced with a simple comparison.
* sMathML3Attributes is split into two tables: one for script attributes which
will be handled in bug 1548471 and one for style attributes, handled here.
The attributes in this second table is now ignored when the feature flag is
disabled.
* test_bug553917.html is updated so that it no longer checks the old warning
messages for these attributes. New warning messages have been verified
manually.
* Reftests checking support for these attributes are run with the support
enabled.
* Finally, WPT tests are run with the support disabled and a new test
is added to verify that these attributes are no longer mapped to CSS.
Differential Revision: https://phabricator.services.mozilla.com/D43111
--HG--
extra : moz-landing-system : lando
This commit introduces new counters and deprecation warnings for the following
MathML features:
* mathspace names (bug 1575542)
* mathsize names (bug 1548527)
* linethickness names (bug 1548529)
Note: helper parsing functions for mfrac and mpadded are changed to non-static
in order to pass the document parameter needed to log warnings to the console.
Change manually tested with
<math>
<mspace width="thinmathspace"></mspace>
<mpadded width="2thickmathspace"></mpadded>
<mfrac linethickness="thin"><mn>1</mn><mn>2</mn></mfrac>
<mtext mathsize="big">3</mtext>
</math>
Differential Revision: https://phabricator.services.mozilla.com/D42890
--HG--
extra : moz-landing-system : lando
When privacy.spoof_english = 2, we should hide the user's
locale in content. So we use en-US default strings for HTML
form elements, such as a Submit button.
We also force GetLocalizedEllipsis() to always return the
ellipsis used by en-US.
Differential Revision: https://phabricator.services.mozilla.com/D35815
--HG--
extra : moz-landing-system : lando
This gets rid of the sending warnings to the browser console. Instead, when the processor is explicitly asked to do so, it now collects spec violations into a `moz_validation` member.
To access the new manifest member, you can now pass a second argument to `ManifestObtainer.contentObtainManifest()` like so:
```
const manifest = await ManifestObtainer.contentObtainManifest(
this.targetActor.window,
{ checkConformance: true }
);
manifest. moz_validation; // 🎉
```
Differential Revision: https://phabricator.services.mozilla.com/D36885
--HG--
extra : moz-landing-system : lando
The bounds attribute has been deprecated and shown zero use, and thus this change removes it.
Differential Revision: https://phabricator.services.mozilla.com/D36005
--HG--
extra : moz-landing-system : lando
We move the check of important rule and animation level into
KeyframeEffect::ShouldBlockAsyncTransformAnimations(), and add a new warning
for it.
Note:
1. ShouldBlockAsyncTransformAnimations() only cares about transforms. And
for other compositor animation properties, we count on
HasEffectiveAnimationOfPropertySet() (in IsMatchForCompositor()).
2. If we check the important rules in both
EffectCompositor::HasAnimationsForCompositor() and
ActiveLayerTracker::IsTransformMaybeAnimated(), we may get the incorrect
animation warnings (i.e. TransformFrameInactive). In most cases, we
check these two functions together, so perhaps move the check of important
rules outside HasEffectiveAnimationOfPropertySet() is fine.
Besides, ActiveLayerTracker just tracks if there is a style change on this
property (or display item) on the active layers, so should be OK to not
check important rules in it.
So IsMatchForCompositor() should check all transform-like properties,
instead of each one, to get the correct result. (That's why we have to
refactor KeyframeEffect::GetPropertiesForCompositor() as well.)
Differential Revision: https://phabricator.services.mozilla.com/D34432
--HG--
extra : moz-landing-system : lando