Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
Process and non-process managers have different script loader interfaces
(ProcessScriptLoader/GlobalProcessScriptLoader vs FrameScriptLoader). The WebIDL
conversion used the same interface for some process and
non-process managers, but because of the different script loader interfaces they really
should be using separate interfaces.
Our behavior is correct, this uses the same setup that nsDocument and the
stylesets use, which I may look into fixing up / making more explicit in
bug 1465031.
MozReview-Commit-ID: 75AToXCw1pV
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
This is sound because the unlink implementation of the stylesheet drops the
preserved wrapper, and there are no strong references back to any node from the
stylesheet or any of the non-unlinked members.
This almost is the same setup that works for document sheets. We need to account
for a double reference in case the sheet is applicable because Servo keeps
another reference to it in that case, instead of in the StyleSet / PresShell.
Added the testcase as a crashtest, in the hopes that if it regresses leak
reporting on automation will catch it.
MozReview-Commit-ID: Kcc5oaOvP9A
The dirty bit fiddling is nontrivial, but it's pretty much what we do for
invalidation and allows to keep this incrementally easily.
The only caller that we cared about for the GetFlattenedTreeParent check in
DestroyFramesForAndRestyle was the old ShadowRoot invalidation functions that
went away.
MozReview-Commit-ID: GmgPPJ6d2qX
Summary:
When the host is bound to the document, it'll also re-BindToTree the shadow
tree, which will update the stylesheets and all that.
Reviewers: xidorn
Bug #: 1446507
Differential Revision: https://phabricator.services.mozilla.com/D742
MozReview-Commit-ID: fBLq5owB7U
Summary:
Also, make stuff sound in presence of CSSOM and what not.
The dirty: false thing is reverting an accidental change that landed in the
de-XBL stuff, which was harmless, but now wouldn't let me assert stuff properly.
Reviewers: xidorn
Bug #: 1445682
Differential Revision: https://phabricator.services.mozilla.com/D748
MozReview-Commit-ID: K0W2Rv0qK8X
Summary:
Before that bug, we carefully told layout about all distribution changes before
they happened, so layout could cleanup frames and styles synchronously properly
(since otherwise there's no way afterwards to figure out what the tree shape
was).
That bug made it not do it correctly, causing this.
I obviously need to write a bunch of tests for this...
Reviewers: smaug
Bug #: 1438210
Differential Revision: https://phabricator.services.mozilla.com/D724
MozReview-Commit-ID: 8uupNhoFwme
More improvements to come. In particular, this still iterates through Shadow DOM
in each_xbl_cascade_data, but that should be changed later. That allows to
cleanup a bunch of stuff and finally fix Shadow DOM cascade order.
We still rely on the binding parent to be setup properly in the shadow tree, but
that requirement can go away later (we can walk the containing shadow chain
instead).
This mostly focuses on removing the XBL binding from the Shadow host.
It'd be nice to do EnumerateShadowRoots faster. I think that should also be a
followup, if needed.
MozReview-Commit-ID: Jf2iGvLC5de
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
Now that accessing nsIContent slots is not a blob of virtual function calls, we
should be able to unify logic here, and speed up the not-so-rare case for
chrome, while keeping the usual case fast.
MozReview-Commit-ID: 87iY5Cbhx4T
