Change exception type to comply with HTML spec, which uses security
error instead of bad document domain.
MozReview-Commit-ID: Iefkeskn9bM
--HG--
extra : rebase_source : 282507d687c8fe19a326df95632694bcc6c5dd29
Make document.domain non-nullable, to conform to the HTML spec.
MozReview-Commit-ID: B1YuQekBgZD
--HG--
extra : rebase_source : 00999e16549e62c783f06f61c62000ab7677cf1d
We currently observe changes to HTMLMediaElement::mPaused via a hand-rolled
wrapper class. We can use use mozilla::Watchable<> and avoid rolling our
own equivalent here.
This also paves the way for using state watching on other observable state
in HTMLMediaElement.
MozReview-Commit-ID: 4lBlJiV15iG
--HG--
extra : rebase_source : 22f9d811371f9d609dc96a9d958645e5c634eb17
extra : intermediate-source : bdb8280da440a711c6cd51b65ead7ba9e4bb3597
extra : source : fd8c4b8656a9996eea94d2092caaf3c10fe2a835
We don't need to track this state anymore, as we don't need to delay calling
MediaDecoder::Play() or delay firing the "playing" event anymore.
MozReview-Commit-ID: E3B9l6ep7FP
--HG--
extra : rebase_source : 63df836bf0249ed40b0659cd42794e92966cefb9
I don't think we should allow media without audio tracks to autoplay because:
* It means play() before loaded metadata behaves differently than play()
called after loaded metadata.
* With the current impl we dispatch the "play" event and then the "pause"
event when we decide we should block, which may confuse some sites' controls.
* Delaying running the play() algorithm until we've loaded metadata would add
significant complexity, and may break sites.
* Chrome doesn't have this provision, meaning the complexity required to
support it will not result in much benefit to us.
MozReview-Commit-ID: FSVlDJAOisw
--HG--
extra : rebase_source : 93b1bcf8d8edbd6ca10ad918b40a87cd3cfbbf0b
This patch splits FontTableURI and BlobURL in 2 classes:
FontTableURIProtocolHandler and BlobURLProtocolHandler
both under mozilla::dom.
It also removes a memory reporter because that report is already covered by the
BlobURL one.
--HG--
rename : dom/file/nsHostObjectProtocolHandler.cpp => dom/file/BlobURLProtocolHandler.cpp
rename : dom/file/nsHostObjectProtocolHandler.h => dom/file/BlobURLProtocolHandler.h
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
When we implement InputEvent.inputType, we need to set a stack class to record
which edit action is currently handled. However, currently, we call smaller
jobs as edit action. For example, when user types a character at selecting
some characters, then, EditAction::deleteSelection is performed first, then,
EditAction::insertText is performed. However, for the InputEvent.inputType,
we need inserText information. So, for making new enum EditAction, we need
to rename current EditAction to EditSubAction.
And also this renames related stuff:
EditorBase::mIsInEditAction -> EditorBase::mIsInEditSubAction
EditorBase::IsInEditAction() -> EditorBase::IsInEditSubAction()
EditorBase::mAction -> EditorBase::mTopLevelEditSubAction
TextEditRules::mTheAction -> TextEditRules::mTopLevelEditSubAction
EditorBase::StartOperation() ->
EditorBase::OnStartToHandleTopLevelEditSubAction()
EditorBase::EndOperation() ->
EditorBase::OnEndHandlingTopLevelEditSubAction()
AutoRules -> AutoTopLevelEditSubActionNotifier
RulesInfo -> EditSubActionInfo
MozReview-Commit-ID: cvSkPUjFm1
--HG--
extra : rebase_source : baf527a3e353b7a8ebe9a46be2243b059c500234
New windows cannot execute fullscreen requests until after the first
MozAfterPaint event has been fired on the window, because some of the
machinery in browser-fullScreenAndPointerLock.js isn't initialized until
that point. This test exercises that behaviour, and therefore should also
wait until the first MozAfterPaint before requesting fullscreen.
MozReview-Commit-ID: Igy7WfjslWA
--HG--
extra : rebase_source : 4b16293a107468bd53b8d1f54560b8acf326631f
Before that we were not notifying the image frame in any way if we ended up not
doing a load, and we were instead relying on the reflow the viewport resize
caused to get the new density in ComputeSize from the content node (but nowhere
else, since that's the bug part 1 fixes).
This was generally unsound, since you can stash random media in a sizes=
attribute, which don't necessarily needs to cause a reflow.
Now we need to notify necessarily because nsImageFrame stores the adjusted
intrinsic size.
mCurrentDensity could also get out of sync as well, when the selected image
density changed, but we ended up returning early because our source hadn't
change in the first early exit.
This patch moves us to a model where we don't re-trigger loads for density
changes if the source doesn't change (unless we pass aAlwaysLoad when we need
to, per spec).
This matches our previous behavior (without the bugginess of not updating the
intrinsic size), and also Chromium, at least.
This changes behavior in one case, which is when we don't load the same source
node, but we have the same source URL, and the density does change. This could
happen with <picture> and two <source>s with same source and different media and
sizes. This makes our behavior consistent with the behavior we have when both
the source and the density doesn't change.
Blink and WebKit do trigger a second image load both when the source changes
without changing density and when density changes. I'll file a spec issue, since
per:
https://html.spec.whatwg.org/#reacting-to-environment-changes
We should be triggering the load when the density changes but the source
doesn't as well, but no UA does that.
I filed https://github.com/whatwg/html/issues/3709 with a little summary of the
situation and what I think the behavior should be (which is what this patch
implements). That being said, I'll update the impl if the spec people think
otherwise :).
MozReview-Commit-ID: Eqy16ygHRLo
Only doing it in ComputeSize (via GetNaturalSize) is unsound, and the rest of
the users of mIntrinsicSize definitely do need scaling accounted for.
Move the adjustment to nsImageFrame for two reasons:
* Prevents adding more dependencies from nsIImageLoadingContent, which
otherwise would need to go away anyway in bug 215083.
* Avoids having to duplicate the image orientation logic, since mImage is
already an OrientedImage if needed.
MozReview-Commit-ID: EA0n0TctZhN
When using a media element with a Media Source, the resource fetching algorithm is to be called in "local" mode:
https://www.w3.org/TR/media-source/#mediasource-attach
"Continue the resource fetch algorithm by running the remaining "Otherwise (mode is local)" steps, with these clarifications"
https://html.spec.whatwg.org/multipage/media.html#concept-media-load-resource
Under the local mode, the steps that would cause the element to fire suspend, stalled or progress can never occur.
We only prevent the stalled event to be fired, many websites rely on the progress event to be fired (such as when the init segment has been parsed). The HTML5 media spec will be amended to clearly indicate that progress is to be fired even with mediasource
MozReview-Commit-ID: DkoQzoV0JzO
--HG--
extra : rebase_source : 1e916eee50c9935f168797bb5a92052191cda59d
Partially apply clang-format so that we limit the scope of changes while ensuring consistency in declarations.
MozReview-Commit-ID: Km9sKBbFhKx
--HG--
extra : rebase_source : 880e1fc1b46ab57d961e12eb7670260128d0faa1
There are a few things going on here:
1) Better tracking of whether we've done our synthetic document stuff so we
don't redo it when it's not needed. We should only be doing it on initial
load.
2) Better handling of our readystate transitions. We're only responsible for
the transition to READYSTATE_INTERACTIVE if we're the ones setting up the DOM.
Otherwise whoever is doing that should do the readystate transition.
Both of these really use the same mechanism, which is why I ended up doing them
together.
Currently we can end up dispatching a 'playing' event right before we reject
play() promises, and this confuses YouTube's controls, and it doesn't make
sense to dispatch a 'playing' event when we're not playing anyway.
This is because the logic to delay resolving the play() promise until after
we've reached loadedmetadata doesn't prevent the 'playing' event from being
dispatched. We shouldn't dispatch 'playing' until we resolve the play()
promise(s).
MozReview-Commit-ID: 5H4dcObfu4M
--HG--
extra : rebase_source : b4036a8fead95cd3070f9fc4d30e0feb23d1f64c
Now that BeginUpdate is useless for the UPDATE_STYLE case, we don't need the
update mechanism at all. Just ensure that ApplicableStylesChanged is called on
the pres shell via the relevant RuleChanged, etc. notifications.
There's a big hidden gotcha here. nsIDocument::BeginUpdate does put a script
blocker on the stack for these updates. However it's not needed, since no script
can run during these notifications (only the stylesheet events we post for
devtools, but those use AsyncEventDispatcher and PostDOMEvents, so they don't
try to run immediately).
nsIDocument::BeginUpdate also does XBL binding attached queue stuff, but we
can't change bindings during these notifications anyway, so it also doesn't
matter.
MozReview-Commit-ID: HJvK6zQfloh
I've kept the nsAutoStrings in the StyleSheetInfo class on the hopes that the
compiler does RVO, but if it doesn't I can remove I guess.
MozReview-Commit-ID: 2vN6BSEhYcw
As part of applet/java plugin removal in bug 1279218, classid checking
was removed, as it was not obvious that this was used anywhere other
than java plugins. The classid is still a valid attribute on object
tags (and is sometimes used on tags for flash embedding). We want
to use a fallback strategy when we find objects with classid
attributes, as we don't support them, meaning we need to revert our
prior removal of the check.
MozReview-Commit-ID: BKQ34HGTkvt
--HG--
extra : rebase_source : 671bc831a7b500ba1a5643a8dbae69dd0c44acf4
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Nothing from within CompatibilityModeChanged can kill it.
MozReview-Commit-ID: 386GiYBC6kF
--HG--
extra : rebase_source : ac93fb98dce07b04381cd5429cb1bc693c1fd07a
