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
log a warning recommending the use of sendBeacon during unload instead of synchronous XMLHttpRequest
Differential Revision: https://phabricator.services.mozilla.com/D23799
--HG--
extra : moz-landing-system : lando
- Change "ServiceWorkerRegisterMimeTypeError" to "ServiceWorkerRegisterMimeTypeError2"
to account for more acceptable MIME types
Differential Revision: https://phabricator.services.mozilla.com/D6416
--HG--
extra : moz-landing-system : lando
This is kind of like the previous patch (where we had a not-very-friendly user experience shutting down misbehaving h2 sessions), but in this case the server has proven to us that it can speak a minimum of h2, so we don't want to just fallback. Instead, when we send a GOAWAY frame because we have detected some error on the part of the server, if it's a top-level page load, we'll show an error page explaining that the server spoke bad http/2, and the site admin(s) need to be contacted. We already did this for INADEQUATE_SECURITY (which is its own special case still), but that didn't cover all the cases.
Differential Revision: https://phabricator.services.mozilla.com/D8436
--HG--
extra : moz-landing-system : lando
When OOMing when allocating the temporary buffer, we return an error from the
ctor via an output parameter, and make the ConvolverNode output silence.
Additionaly, a warning is issued each time we fail to set a buffer to the buffer
property of a ConvolverNode.
Differential Revision: https://phabricator.services.mozilla.com/D6936
--HG--
extra : moz-landing-system : lando
When OOMing when allocating the temporary buffer, we return an error from the
ctor via an output parameter, and make the ConvolverNode output silence.
Additionaly, a warning is issued each time we fail to set a buffer to the buffer
property of a ConvolverNode.
Differential Revision: https://phabricator.services.mozilla.com/D6936
--HG--
extra : moz-landing-system : lando
Log to the web console when we block autoplay, in order to help web developers debug their sites.
Differential Revision: https://phabricator.services.mozilla.com/D4406
--HG--
extra : moz-landing-system : lando
Do it so that we always try to evaluate the media expression and the modern
syntax last, so that the most specific error message comes up.
MozReview-Commit-ID: 2tqdAsWh6Kh
I've made the returned object from .bounds not live. If that's not OK, I'll
resurrect DOMBounds (removed in a previous patch). This also forces
DOMQuad.toJSON() to only return the points.
MozReview-Commit-ID: 10TY5oJUmTN
--HG--
extra : rebase_source : f965bd0593b512ec57ffc5268eecf3b4fe8e820a
I've made the returned object from .bounds not live. If that's not OK, I'll
resurrect DOMBounds (removed in a previous patch). This also forces
DOMQuad.toJSON() to only return the points.
MozReview-Commit-ID: 10TY5oJUmTN
--HG--
extra : rebase_source : ab209d584390c584aa0d0814b4dd2bbf48c6cca3
It's been removed for a while on Nightly without any known regressions. This
gives us a full beta cycle of telemetry and two nightly cycles without the API
before shipping.
This only removes the API, followup work will replace serialization by Servo's,
and remove the remaining DOM interfaces.
MozReview-Commit-ID: 2m1taYg5xEr
We always have one now. So we can remove all the codepaths that attempted to
handle the !mPrincipal case.
We can also remove the nsContentUtils::IsSystemPrincipal(mPrincipal) codepaths,
because that can never happen: DOMParser::Constructor never creates a DOMParser
with a system principal.
MozReview-Commit-ID: EUrGoiI0o3u
Cleanup of all localization notes that refer to entities
that are not listed in the corresponding localization file.
MozReview-Commit-ID: Bl0VU9HoPfa
--HG--
extra : rebase_source : 86680b8ae037783304f045e94c7af7053a0f69e9
This patch disables device sensors except orientation by default.
It implements per-sensor prefs to disable orientation, motion, proximity and ambient light
selectively. The patch also makes the pref checks happen at runtime (versus on process
start) using Preferences::AddBoolVarCache.
The patch also removes the related Event constructors also.
MozReview-Commit-ID: EA8ARjjtlkF
--HG--
rename : dom/events/test/test_bug742376.html => dom/events/test/test_deviceSensor.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_disabled_events.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_eventctors_sensors.html
extra : rebase_source : 39da98ac9226ac727f5197d28561b0b762da06f4
Improves the UI for pages blocked by the enterprise policy manager. These improvements include a new image instead of the generic "info" image and updated, approved strings for the page.
MozReview-Commit-ID: 9d6V9onHGGg
--HG--
extra : rebase_source : d702947924f24d9440455a56b7e2f876ab634464
This patch gently removes support for __exposedProps__ by changing
ExposedPropertiesOnly::check() to always return false, while still
failing silently in deny for some kinds of access.
The tests that I changed all involve testing the behavior with
__exposedProps__. I adjusted them to expect it to fail, or to adjust
the error message they get when they fail. That seemed better than
deleting them entirely.
Note that test_bug1065185.html had a bug, so that it never executed
the first case. I fixed that, and then fixed up the test to work when
__exposedProps__ is not supported.
This also removes various bits of the test framework that use
__exposedProps__, but don't actually need to.
MozReview-Commit-ID: 8fvkAmITmXY
--HG--
extra : rebase_source : ef7e2c55adc12511f17f3865ebb46c343875f0b3
Changes originally landed in bug 1356334:
* Removed SUMO link as a localizable string.
* Updated SUMO link: removed "en-US" from link and "cache" parameter.
* Use ordered placeholder instead of %S.
* Fix typo ("responsing").
* Use "extension" instead of "add-on" in DOM strings for consistency.
* Removed period from KillAddonScriptGlobalMessage, since it's a checkbox.
MozReview-Commit-ID: 5IFH2ruISZb
--HG--
extra : rebase_source : a0e84e5338b22e39c0f629c89b4d4b42b3d6bcbe
If all fields in date/time input box are available but the input element's
value is empty, implies that it has been sanitized. In this case, we'll set the
'bad input' validity state. If any of the fields is cleared, we'll remove the
'bad input' validity state, as incomplete field does not imply 'bad input'.
MozReview-Commit-ID: 4EBpH5CWqXM
In case some legacy third-party things were relying on those files being
under a unix/ directory, revert the part of changeset c94e87a18096 that
renamed global-platform/unix to global-platform/gtk.
--HG--
extra : rebase_source : c0f9e96592822fe2c87e837a27becfde87a76a0c
In case some legacy third-party things were relying on those files being
under a unix/ directory, revert the part of changeset c94e87a18096 that
renamed global-platform/unix to global-platform/gtk.
--HG--
extra : rebase_source : bb78b309fe59ee5f76f276e54539e157eb019e69
As per Bug 1355252, the EME spec requires our
navigator.requestMediaKeySystemAccess() function to reject request for
configurations which don't contain at least one MediaKeySystemCapabilities
(audioCapabilities or videoCapabilities).
That's step 15 of this algorithm:
https://w3c.github.io/encrypted-media/#get-supported-configuration-and-consent
We also shouldn't be assuming that WebM and MP4 normatively imply a specific
set of codecs and codec constraints, as that violates step 10 of the "Get
Supported Capabilities for Audio/Video Type" algorithm.
https://w3c.github.io/encrypted-media/#get-supported-capabilities-for-audio-video-type
Making this change has the effect of causing us to reject configurations with
MediaKeySystemCapabilities where those capabilities don't specify a codec
string.
This patch adds a deprecation warning to encourage authors to make their sites
spec compliant.
MozReview-Commit-ID: 6kM9LATDfy6
--HG--
extra : rebase_source : 96763bd49cbebb81ac565a8862cb0ad97838181f
extra : source : 9df49a410082d68041377dabbbebfb458a580041
The "platform" chrome flag requires an irrelevant "content" chrome
manifest entry, while it's only used for locales. It only has exactly
one use, which can actually be replaced by uses of the "os" flag.
Note, we're doing something similar with the "os" flag for skins in
e.g. browser/extensions/pocket/jar.mn.
Unfortunately, for determinism reasons, the chrome manifest entries from
jar.mn are sorted (per bug 982075), so keeping global-platform/unix
would leave it appearing after /mac, and would override it on mac
because of the lack of "os" flag on the /unix entry (we can't put "os"
flags on that entry because we can't do something like os!=Darwin &&
os!=WINNT). So we move it to /gtk such that it always comes before /mac.
--HG--
extra : rebase_source : aaace8147ea54f74aef8a7b2314ad022e9f9be23
Preliminary telemetry indicated 15% of users of EME are in an insecure
context. We'd better log a warning to the web console to inform authors
that their sites will stop working, rather than just breaking them!
MozReview-Commit-ID: CZasdbcC1jS
--HG--
extra : rebase_source : 008b9669d06a77bb133459df6479625ed47249a0
Preliminary telemetry indicated 15% of users of EME are in an insecure
context. We'd better log a warning to the web console to inform authors
that their sites will stop working, rather than just breaking them!
MozReview-Commit-ID: CZasdbcC1jS
--HG--
extra : rebase_source : 685a36be1601215aff4e962fd206d1332abbff79
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
These messages will be displayed in the Decoder Doctor drop-down notification
bar.
The message ids are also used internally to identify corresponding issues.
MozReview-Commit-ID: MmKxCEoTok
--HG--
extra : rebase_source : 8bc15e16e48f137db17892604d9f1257e8485612
Even for very small layers we want to avoid doing work on the main
thread.
At the same time, however, increase the minimum active layer size for
animations which come from restyles. These involve the main thread
anyway, so there is less to be gained from using an active
layer. Since switching items between active and inactive can have
large knock-on effects, we want to make sure it really is worth making
the layer active.
MozReview-Commit-ID: 8N6xlVW4Dp3
--HG--
extra : rebase_source : bd9a97899faaf187e5e148126711bb0ff5a29ee6
For components also referencing it in code, see the blockers of bug 1336311.
MozReview-Commit-ID: 4tUZ24HKBWy
--HG--
extra : rebase_source : ec16149f525b9b7eaca7f96f1369929d21497121
The Adobe CDM is being removed, leaving only the Widevine CDM. So it doesn't make
sense to have the string refer to Adobe.
MozReview-Commit-ID: 6jjI6Q7BwWX
--HG--
extra : rebase_source : f1aa42bbb8e55b97cac88295ba54780378ba8dfa
Note that the default values of the prefs are chosen so as to preserve
existing behaviour.
The patch also updates a user-visible warning message, which was
already out of date as of bug 1274991.
MozReview-Commit-ID: AqBBoIucShT
--HG--
extra : rebase_source : 010aa55255d49e4875cb6870f309649a9ca762d5
This patch adds a new performance warning type for the case when we start
a transform animation at the same time as an animation that includes a
geometric property. In that case we run the transform animation on the main
thread so that it is synchronized with the geometric animation (which we can
only run on the main thread).
This differs from CompositorAnimationWarningTransformWithGeometricProperties
in that this applies across different elements whilst the existing warning
only covers the case when the same animation animates both transform and
geometric properties.
MozReview-Commit-ID: EcOMo4VDAYY
--HG--
extra : rebase_source : b4bbc3e4ffa69d0d741fe6d67aba0349b9325b3e
extra : histedit_source : 9fd1b33e8776e270241cde40f1905e74fdfcb630
If libavcodec is present but cannot be used, Decoder Doctor sends a distinct
notification to better help the user find the issue.
MozReview-Commit-ID: IGXPIY1b8AS
--HG--
extra : rebase_source : e2884e442f611464bd995e0b2d8b32bec05a148a
Deprecated ImageBitmapRenderingContext.transferImageBitmap and replaced
it with ImageBitmapRenderingContext.transferFromImageBitmap.
MozReview-Commit-ID: BbNgKrluhT7
--HG--
extra : rebase_source : 2aa3dbfc3acc5d8b1e451111ddbb2cac63f40433