This also removes the following prefs, because they're unused:
- media.autoplay.allow-muted pref
- media.autoplay.blackList-override-default
Differential Revision: https://phabricator.services.mozilla.com/D36396
--HG--
extra : rebase_source : 0570540496302b3efedadf4d5115ee5422d5c279
Per spec, "border" is parsed as a non-negative integer, only mapped if nonzero
(though this is not observably different from mapping even if 0, except if user
or UA stylesheets style the border), and supported on img, object,
<input type="image">, but NOT embed, iframe, or marquee.
This matches the Chrome and Safari behavior, as far as I can tell. The
substantive change here is that we are removing mapping for the <embed border>
case.
Differential Revision: https://phabricator.services.mozilla.com/D36376
--HG--
extra : moz-landing-system : lando
Per spec, "hspace" and "vspace" are parsed as dimension attributes and are
supported on the following elements: embed, iframe, img, object,
<input type="image">, marquee. Except no one implements this for iframe.
https://github.com/whatwg/html/issues/4742 tracks the spec changing accordingly.
As far as hspace/vpace on <table> go, Safari supports them in both quirks and
standards mode, while Chrome doesn't support them in either mode. The HTML spec
doesn't have them supported at all, and neither does the quirks mode spec, so
I'm removing the quirks-only support we had to align with the specs and Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D36375
--HG--
extra : moz-landing-system : lando
The various margin attributes on <body> are "pixel length attributes" in the
spec, which should get parsed as non-negative integers. That said, Chrome and
Safari implement marginwidth, marginheight, marginleft, and margintop as
"dimension attributes" instead, and don't implement marginright and marginbottom
at all.
Differential Revision: https://phabricator.services.mozilla.com/D36372
--HG--
extra : moz-landing-system : lando
"charoff" isn't parsed specially in the spec, and nothing in our code uses the
parsed value.
Differential Revision: https://phabricator.services.mozilla.com/D36369
--HG--
extra : moz-landing-system : lando
It mostly works out, because we return an int32_t then just cast it to uint32_t,
but it would be better to return the right thing to start with.
Differential Revision: https://phabricator.services.mozilla.com/D36129
--HG--
extra : moz-landing-system : lando
We don't need to parse 'width' on <tr> because we never use the parsed value for
anything and neither does the spec.
We don't need to parse 'charoff' on <col> because we never use that for anything
either, and neither does the spec.
Differential Revision: https://phabricator.services.mozilla.com/D36128
--HG--
extra : moz-landing-system : lando
The spec allows non-integer values, but we don't have a good way to store them
in nsAttrValue yet. See https://bugzilla.mozilla.org/show_bug.cgi?id=1561440
HTMLTableCellElement::MapAttributesIntoRule can now call
MapImageSizeAttributesInto instead of manually mapping width and height, because
0 values (which it was excluding before) are now excluded at attribute parse
time.
For 'width' on HTMLTableElement I kept our old behavior for 0, which matches the spec
but not Safari or Chrome.
For 'height' on HTMLTableElement I kept our old behavior for 0, which matches
Safari and Chrome but not the spec. https://github.com/whatwg/html/issues/4715
tracks a possible spec change.
Same thing for 'height' on HTMLTableRowElement.
Same thing for 'width' on HTMLTableColElement.
The ParseImageAttribute call in HTMLMediaElement is not needed, because
HTMLAudioElement does not map any of those to style and HTMLVideoElement only
maps width/height, which it already parses.
Differential Revision: https://phabricator.services.mozilla.com/D36127
--HG--
extra : moz-landing-system : lando
This was done as a catch-all in PlaybackEnded(), but playback might not end if
the source changes in the middle of playback. This catches those cases too.
Differential Revision: https://phabricator.services.mozilla.com/D35321
--HG--
extra : moz-landing-system : lando
HTMLMediaElement::mUnboundFromTree was added in bug 1239899, and I'm pretty
sure its behaviour is intended to be the same as what IsInComposedDocument()
gives us, so we can just use that instead.
Differential Revision: https://phabricator.services.mozilla.com/D35295
--HG--
extra : moz-landing-system : lando
Video tracks are not added to output streams that capture only audio, so we
cannot assume that an output stream that captures only audio has been locked to
capture MediaStream sources when a video track is removed.
Depends on D34854
Differential Revision: https://phabricator.services.mozilla.com/D34855
--HG--
extra : moz-landing-system : lando
This should be the minimal patch to fix the issue (should be safe for branches too).
Reusing an existing mouse/touch test for the crash testing.
Differential Revision: https://phabricator.services.mozilla.com/D34717
--HG--
extra : moz-landing-system : lando
This FireTimeUpdate(false) dates back to bug 611994. Perhaps it was spec
compliant back in the day, but it surely isn't now.
Differential Revision: https://phabricator.services.mozilla.com/D33651
--HG--
extra : moz-landing-system : lando
Bug 1279865 introduced this under the premise of
"Run TimeMarchesOn() at the beginning of play.", but it did a bit too much.
This makes us spec compliant for this particular case again.
Differential Revision: https://phabricator.services.mozilla.com/D33650
--HG--
extra : moz-landing-system : lando
There are a number of failures, for which I've filed separate bugs.
And then a lot of fuzziness. I manually inspected the reftest analyzer
results on try pushes to distinguish failures vs fuzziness.
Depends on D34537
Differential Revision: https://phabricator.services.mozilla.com/D34538
--HG--
extra : moz-landing-system : lando
HTMLMediaElement::CanActivateAutoplay() had an exception for MediaStreams in its
check for whether autoplay can be activated. This removes that exception and
requires us to be in HAVE_ENOUGH_DATA regardless of source, per spec.
Doing this broke autoplay of an ended media element that's playing a
MediaStream, since autoplay of this MediaStream could no longer be immediately
activated. The exact sequence algorithm for autoplaying the stream in this case
is not defined in mediacapture-main, but we know we must reach HAVE_ENOUGH_DATA
to play, and we must run the load algorithm to reach HAVE_ENOUGH_DATA, that's
what we do:
When the MediaStream we're autoplaying once again becomes active, we run the
media element load algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D33298
--HG--
extra : moz-landing-system : lando
Unsetting a playing video element's MediaStream-srcObject attribute will
otherwise leave the element displaying the latest frame of the video track.
Differential Revision: https://phabricator.services.mozilla.com/D33295
--HG--
extra : moz-landing-system : lando
This allows it to intercept frames in the rendering pipe, so that we don't have
to duplicate the logic for converting VideoChunks to NonOwningImages.
Differential Revision: https://phabricator.services.mozilla.com/D33292
--HG--
extra : moz-landing-system : lando
`Document::ExecCommand()` knows subject principal. This patch makes it tell
`EditorCommand::DoCommand()` and `EditorCommand::DoCommandParam()`. Then,
makes they tell each editor public methods which may cause dispatching
`beforeinput` event once we implement it. Finally, each editor public
method sets it to the constructor of `EditorBase::AutoEditActionDataSetter`.
This means that when editor tries to dispatch `beforeinput` event, editor
can check whether it's called by JS or not from everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D29635
--HG--
extra : moz-landing-system : lando
Since the Firefox print preview code creates a static clone from the existing
print preview static clone for any print preview settings changes, for enabling
of simplified mode, and for a print from a print preview document,
HTMLCanvasElement::CopyInnerTo may be invoked on an existing static clone.
In that case, the mozPrintCallback's printState.context.canvas would previously
have ended up using the canvas in the previous print preview static clone,
which is wrong, and allow the callback to modify the static clone document.
Differential Revision: https://phabricator.services.mozilla.com/D34294
--HG--
extra : rebase_source : ef9b360bac674a22cbc3c505ce30089a9d25bb22
extra : amend_source : f449821674a4b4aa45df924f89eec015cae907a9
