Also, change DocumentFragment to use RefPtr, since that's the usual style.
MozReview-Commit-ID: 4PQ19nbmhUh
--HG--
extra : rebase_source : 2afb214b764ba48a4a8718190a6853ae6d6ea80b
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : f2a17aee7bb66a7ba8652817d43b9aa7ec7ef710
During a frame swap (using the `swapFrameLoaders` API on a frame loader owner),
we dispatch `pagehide` events before swapping and `pageshow` events after
swapping.
For some consumers that watch these events (such as DevTools), it would be
helpful to filter out the ones that sent because of frame swapping. This change
adds a chrome-only `inFrameSwap` property to such events so that we can tell
them apart.
MozReview-Commit-ID: QzIDuaF2zC
--HG--
extra : rebase_source : 3ac15e34c18b648c4cb060e69587e39e4ebaab60
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : 592d13349a8c4627c7ce3146ec592f577b39f3cc
We used to do it this way effectively until I fixed it in bug 1400936.
Per the list of fuzz bugs that bug has in the "Depends on" field, some of those
without a super-clear fix, and others that aren't listed in there, and all the
complexity we had to deal with while receiving restyle requests mid-unbind, etc,
I think this is the right call.
This clears data on RestyleManager::ContentRemoved for non-anonymous nodes, and
on UnbindFromTree for subtrees rooted at anonymous nodes.
This will hopefully yield enforceable invariants.
MozReview-Commit-ID: IMwX5Uh1apv
Just expanding the assertion to cover shadow trees.
MozReview-Commit-ID: FLE0noGzaIF
--HG--
extra : rebase_source : fa68f04b8095bd48eab598415e1700620ecce092
Pretty much the same way as what we do on XBL insertion point changes, since the
data would be stale.
I think both of those are kind of a hack, btw, and that we could fix it doing
ClearServoDataFromSubtree properly before we start unbinding. That'd prevent all
these issues, and all the complexity that entails receiving restyle requests
mid-unbind (we'd guarantee the tree is always in a stable state).
That's a matter of a different bug though.
MozReview-Commit-ID: Ev6RvGuPGiv
--HG--
extra : rebase_source : 8ae0db799282bfb8ca2385d6997763f29a082c61
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because the current compartment is used in the
following places and all of them are safe:
1. GlobalObject::CallerType(), that is ultimately passed to
nsDocument::IsWebAnimationsEnabled in KeyframeEffectParamsFromUnion,
to decide whether to copy mIterationComposite/mComposite to
KeyframeEffectParams.
GlobalObject::CallerType() can now be different than the target window's one,
if the caller has the system principal and the target is web content, and
in that case nsDocument::IsWebAnimationsEnabled there always returns true
while Web Animations can be disabled on web content.
honoring the mIterationComposite/mComposite properties is OK, since it just
changes the animation behavior, and this is disabled by default until
remaining spec issues are resolved.
2. GlobalObject::Context(), that is ultimately passed to
KeyframeUtils::GetKeyframesFromObject and used while extracting information
from passed-in keyframe object, with iterable/iterator protocols.
Performing that operation in the caller side is okay, since the same thing
can be done on caller, and the operation doesn't perform any GCThing
allocation on the target window global.
Also, make them not rebuild the CascadeData synchronously, via the
FlushSkinSheets call, since that's broken. That fixes bug 1413119.
This is a little step in getting rid of XBL usage for Shadow DOM.
MozReview-Commit-ID: HJ7FeUZlRTW
--HG--
extra : rebase_source : 0fcd0ed461856c1e87e45ef63c9e1d2e81281469
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because of the following reasons:
1. The target window global is used for most operation:
* KeyframeEffectReadOnly::ConstructKeyframeEffect uses the target window
global instead of current global.
* KeyframeEffectParamsFromUnion which receives `aGlobal.CallerType()`
In Xray case, Web Animations API can be disabled on web content
(currently disabled on beta/release by default), and in that case some API
won't work even it's triggered from WebExtensions, but it should be fine.
2. GetKeyframesFromObject is executed in the caller's compartment to access
the passed-in JSObject that is keyframe, with iterable/iterator protocols.
This operation doesn't perform any GCThing allocation on the target window
global.
This change prevents URLs with wyciwyg schemes to be set as mDocumentURI.
Otherwise, in JS, document.URL returns a wyciwyg://* URL and a subsequent
call to document.write makes wycywyg URL visible in the address bar.
MozReview-Commit-ID: BaKpDkkIYbM
--HG--
extra : rebase_source : cc14c247e4aaa43645481cbc520040eacbba6e21
When the window is destroyed in unload event callbacks for the previous
document, we haven't started loading, i.e. we haven't called BlockOnload()
for the new document in nsContentSink::WillBuildModelImpl, so if we called
nsDocument::StopDocumentLoad() in such cases, UnblockOnload calls will mismatch
BlockOnload calls.
MozReview-Commit-ID: HjLtmGGvXKS
--HG--
extra : rebase_source : 8d81afd5cd7988cb165d9fee5dcfbf5fbf702331