This patch is generated by using my editor's rename functionality.
In the next patch, `nsIFrame::` prefix is going to be removed manually
from all the ChildLists() calls.
Differential Revision: https://phabricator.services.mozilla.com/D75893
For now, always pass null, except when passing it through from one
overload to another.
Differential Revision: https://phabricator.services.mozilla.com/D38389
--HG--
extra : moz-landing-system : lando
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
In each file touched by this commit, there were no mentions of nsAutoPtr
besides the #include.
I verified that the folder layout/base still builds successfully in
non-unified mode after this patch, too. So, none of these files are secretly
using nsAutoPtr and depending on some other .cpp file to provide the header.
Differential Revision: https://phabricator.services.mozilla.com/D12993
--HG--
extra : moz-landing-system : lando
For each file touched in this patch, the file had an #include for nsContentUtils.h, but no other mentions of the string "nsContentUtils", nor any mention of its "ScriptBlocker"-related types. So these files likely don't need their nsContentUtils.h include anymore, and we can remove it to get a marginal win on build time/complexity.
Differential Revision: https://phabricator.services.mozilla.com/D3370
--HG--
extra : moz-landing-system : lando
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
This is mostly code removal, changing GetDisplayContentsStyle(..) checks by an
FFI call to Servo.
The tricky parts are:
* MaybeCreateLazily, which I fixed to avoid setting bits under display: none
stuff. This was a pre-existing problem, which was wallpapered by the
sc->IsInDisplayNoneSubtree() check, which effectively made the whole
assertion useless (see bug 1381017 for the only crashtest that hit this
though).
* ContentRemoved, where we can no longer know for sure whether the element is
actually display: contents if we're removing it as a response to a style
change. See the comment there. That kinda sucks, but that case is relatively
weird, and it's better than adding tons of complexity to handle that.
* GetParentComputedStyle, which also has a comment there. Also, this function
has only one caller now, so we should maybe try to remove it.
The different assertions after DestroyFramesForAndRestyle are changed for a
single assertion in the function itself, and the node bit used as an
optimization to avoid hashtable lookups is taken back.
MozReview-Commit-ID: AZm822QnhF9
Instead move UndisplayedNode to its own file, which is what causes the include
hell due to requiring nsIContent / nsStyleContext.
MozReview-Commit-ID: 1opiajueZNb
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
The failure mode in the attached crashtest is an inconsistency in the flattened
tree. Specifically, we null out mVideoControls in an nsVideoFrame, but defer
the UnbindFromTree call on that NAC element, which measn that its mParent still
points to the nsVideoFrame's mContent. Because all this stuff runs off of script
runners, and the anonymous content destroyer is not guaranteed to run before
other potential script runners, we end up running arbitrary script while the
tree mismatch exists. This script calls back into ProcessPendingRestyles, which
causes trouble.
We could build a separate deferral mechanism, but it's not clear that we actually
need to defer the unbind anymore. The deferred unbind was added in bug 489008,
which predated a lot of simplifications in layout/dom interaction.
MozReview-Commit-ID: 1JYAhiXKVJC
We have four entry points that deal with the parents of display:none/
display:contents content. These are the functions for setting, changing,
getting and removing a style context. Or more specifically:
GetUndisplayedNodeInMapFor
called by GetDisplay[None|Contents]StyleFor (via GetStyleContextInMap)
SetStyleContextInMap
called by RegisterDisplay[None|Contents]StyleFor
ChangeStyleContextInMap
called by ChangeRegisteredDisplay[None|Contents]StyleFor
UnregisterDisplay[None|Contents]StyleFor
okay, this is actually two functions, but they act as a pair
This change makes all these functions call GetApplicableParent up front and act
on and pass around the parent that it returns. This is so that throughout
the code we are always handling the parent that will be used as the key in
the UndisplayedMap entry. This is necessary so that all the code that
sets/gets the 'MayHaveChildrenWithLayoutBoxesDisabled' bit on/from an
nsIContent object is using the same object, otherwise everything breaks down.
MozReview-Commit-ID: 6gso1tyr33E
Kagami Sascha Rosylight
Ting-Yu Lin
L. David Baron
Cameron McCormack
Narcis Beleuzu
Masayuki Nakano
Emilio Cobos Álvarez
Sylvestre Ledru
Daniel Holbert
Brindusan Cristian
Chris Peterson
Nika Layzell
Jonathan Watt
Xidorn Quan
Noemi Erli
Bobby Holley
Michael Kaply
Mats Palmgren