Some steps in file_fullscreen-api.html are adjusted in order to test
the behavior that the event is correctly dispatched to the document
when element is disconnected.
Depends on D5415
Differential Revision: https://phabricator.services.mozilla.com/D5416
--HG--
extra : moz-landing-system : lando
The MozAutoplayMediaBlocked event should have its target set to the video
element, not the document.
Also, MozNoControlsBlockedVideo event has to initialized from the CustomEvent
constructor of the right window for the XBL binding to access it. I don't know
when it stopped working.
Test is added to ensure the entire UI won't break.
Differential Revision: https://phabricator.services.mozilla.com/D5801
--HG--
extra : moz-landing-system : lando
With UA Widget, the videocontrols container is created lazily.
It won't be a problem for WebVTT.processCues() in vtt.jsm, so
TextTrackManager::UpdateCueDisplay() should not early return there, but pass
nullptr to it.
Differential Revision: https://phabricator.services.mozilla.com/D3667
--HG--
extra : moz-landing-system : lando
This is a follow up to Bug 1482667. The list of callers was gathered by instrumenting
the webidl calls to these methods and dumping JS stack when they are called in browser.xul.
Differential Revision: https://phabricator.services.mozilla.com/D5185
--HG--
extra : moz-landing-system : lando
nsISHEntry.index is readonly, but if you pass `true` as getEntryAtIndex()'s
second argument, nsISHEntry.index will be modified. This is pretty gross.
This patch changes `index` so it's not readonly (because it's not!) and removes
getEntryAtIndex()'s second argument.
--HG--
extra : rebase_source : c519d77fcc1c3bda2f260b5888ce9cd0f6cfdab5
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
"blocked" event is used for testing.
"MozAutoplayMediaBlocked" event is used for changing the control UI on Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D4267
--HG--
extra : moz-landing-system : lando
When `document.blockParsing()` is called, the nsIParser is suspended
until the document is unblocked. For about:blank documents, this is a
nsParser.
When a document is unblocked, nsParser::ContinueInterruptedParsingAsync
is invoked, which delegates its implementation to nsIContentSink, which
is a nsHTMLContentSink for about:blank documents. Due to a missing
implementation of nsHTMLContentSink::ContinueInterruptedParsingAsync,
the parser was never resumed, causing bug 1465388 and bug 1407501.
This patch fixes the problem, by implementing the required method (and
using a load blocker to ensure that the (about:blank) document does not
finish before the parser finishes).
This patch is tested through extension tests: Currently document_start
stylesheets always activate the parser blocker, and document_start
scripts trigger the parser blocker when the script has not been
preloaded yet (e.g. at the first run).
Before this patch, the test failed due to the assertion failure as
reported in the linked bugs. After this patch, the tests pass.
Differential Revision: https://phabricator.services.mozilla.com/D4352
--HG--
extra : moz-landing-system : lando
When `document.blockParsing()` is called, the nsIParser is suspended
until the document is unblocked. For about:blank documents, this is a
nsParser.
When a document is unblocked, nsParser::ContinueInterruptedParsingAsync
is invoked, which delegates its implementation to nsIContentSink, which
is a nsHTMLContentSink for about:blank documents. Due to a missing
implementation of nsHTMLContentSink::ContinueInterruptedParsingAsync,
the parser was never resumed, causing bug 1465388 and bug 1407501.
This patch fixes the problem, by implementing the required method (and
using a load blocker to ensure that the (about:blank) document does not
finish before the parser finishes).
This patch is tested through extension tests: Currently document_start
stylesheets always activate the parser blocker, and document_start
scripts trigger the parser blocker when the script has not been
preloaded yet (e.g. at the first run).
Before this patch, the test failed due to the assertion failure as
reported in the linked bugs. After this patch, the tests pass.
Differential Revision: https://phabricator.services.mozilla.com/D4352
--HG--
extra : moz-landing-system : lando
Since we don't block media without audio track anymore, the original telemetry scalar becomes useless.
We need to change its meaning in order to know the number of allowed autoplay without audio track.
Differential Revision: https://phabricator.services.mozilla.com/D3673
--HG--
extra : moz-landing-system : lando
Add two telemetry scarlar,
"MEDIA_BLOCKED_NO_METADATA" records how many media which was blocked because it hadn't loaded metadata yet.
"MEDIA_BLOCKED_NO_METADATA_ENDUP_NO_AUDIO_TRACK" records how many media which was blocked because it hadn't loaded metadata and ended up for being no audio track.
By collecting those data, we can know the proportion of media which should be autoplay but was blocked because of lacking metadata.
Differential Revision: https://phabricator.services.mozilla.com/D3671
--HG--
extra : moz-landing-system : lando
This matches other implementations and the spec for fallback content like:
<canvas><div>abc
(calling div.innerText).
We're treating the <div> as 'rendered' because it's not in a display: none
subtree, but that's not ok, since it is in fact not rendered.
This was added in bug 1226293, and Boris suggested this change, but roc opposed
because it'd be hard to spec properly in comment 15. Looks like the HTML spec
ended up merging roc's innerText spec, and now it's spec'd in terms of 'being
rendered'.
I think IsOrHasAncestorWithDisplayNone just doesn't work in any reasonable way
for stuff out of the flat tree. Thus I think this change is the right thing.
The canvas test fails because of bug 1485076.
Differential Revision: https://phabricator.services.mozilla.com/D3887
--HG--
extra : moz-landing-system : lando
The mIsTrackingResource flag on nsIHttpChannel was split into two separate
flags depending on whether or not the resource is third-party. The correct
flag will be set by the channel classifier. Similarly, a new function was
introduced, GetIsThirdPartyTrackingResource(), for those consumers (like TP)
who only care about third-party trackers.
The existing function, GetIsTracking(), will continue to look at both
first-party and third-party trackers (the behavior since first party
tracking was added to annotations in bug 1476324).
The OverrideTrackingResource() function now allows nsHTMLDocument to
override both mIsFirstPartyTrackingResource and
mIsThirdPartyTrackingResource, but since this function is a little dangerous
and only has a single user, I added an assert to make future callers think
twice about using it to opt out of tracking annotations.
Currently, only the default storage restrictions need to look at first-party
trackers so every other consumer has been moved to
mIsThirdPartyTrackingResource or GetIsThirdPartyTrackingResource().
This effectively reverts the third-party checks added in bug 1476715 and
replaces them with the more complicated check that was added in bug 1108017.
It follows the approach that Ehsan initially suggested in bug 1476715. It
also reverts the changes in the expected values of the tracking annotation
test since these were, in hindsight, a warning about this regression.
Depends on D3722
Differential Revision: https://phabricator.services.mozilla.com/D3723
--HG--
extra : moz-landing-system : lando
We have another built-in UI of editor which is not implemented by any other
browsers. That is a draggable handler to move absolute positioned elements.
So, we should disable it in default for compatibility with the other browsers.
However, different from resizers and inline table editor, we don't have
command to enable/disable this feature but for backward compatibility, we
should have it. Therefore, this patch adds new command
"enableAbsolutePositionEditor".
Note that whether resizing UI is available only with enableObjectResizing
state is different from enableInlineTableEditing command. Resizers for
absolute positioned elements are NOT available both enableObjectResizing
and enableAbsolutePositionEditor are enabled.
Additionally, this adds automated tests to check basic functions of absolute
positioned editor.
MozReview-Commit-ID: 9ZSGB8tLpFw
--HG--
rename : editor/libeditor/tests/test_resizers_appearance.html => editor/libeditor/tests/test_abs_positioner_appearance.html
rename : editor/libeditor/tests/test_resizers_resizing_elements.html => editor/libeditor/tests/test_abs_positioner_positioning_elements.html
extra : rebase_source : d516f3f3ef36d4ad13938f214cb6e3868d7ff407
This makes things saner for all consumers, which makes it worth doing on its
own. But it also gives me an easy nsTArray to work with, which I can use to
dispatch DOM events with array properties.
Differential Revision: https://phabricator.services.mozilla.com/D3466
--HG--
extra : rebase_source : e8bcc75e84845e42c932886502f99ca3154df48d
Having to add pagehide/pageshow listeners to the chrome event target is a
serious inconvience for the use cases of this bug. Dispatching to system group
listeners has approximately the same effect as the old code, but is much
easier for window-bound code to handle.
--HG--
extra : rebase_source : d67c14e9ba91772d8a9dd82481120b34bdb551e0
This patch introduces a new cookie behavior policy called
BEHAVIOR_REJECT_TRACKER. It also makes it possible to override that
behavior with cookie permissions similar to other cookie behaviors.
The DOM elements within the UA Widget Shadow DOM should have its reflectors in
the UA Widget Scope. This is done by calling nsINode::IsInUAWidget() which
would check its containing shadow and its UA Widget bit.
To prevent JS access of the DOM element before it is in the
UA Widget Shadom DOM tree, various DOM methods are set to inaccessible to
UA Widget script. It would need to use the two special methods in ShadowRoot
instead to insert the DOM directly into the shadow tree.
MozReview-Commit-ID: Jz9iCaVIoij
--HG--
extra : rebase_source : b7b17be68dcde00cfeb207cb39cf16b486f2ab02
