And remove unused includes of nsGkAtoms.h in the process. The few
dependencies have been moved to ServoStyleConstsInlines.h
The used command to remove the now unused dependency was:
git grep -l nsGkAtoms.h | while read line; do grep -v nsGkAtoms.h $line | grep -q -E '\<nsGkAtoms\>' || sed -i -e '/nsGkAtoms.h/d' $line ; done
Differential Revision: https://phabricator.services.mozilla.com/D292697
And remove unused includes of nsGkAtoms.h in the process. The few
dependencies have been moved to ServoStyleConstsInlines.h
The used command to remove the now unused dependency was:
git grep -l nsGkAtoms.h | while read line; do grep -v nsGkAtoms.h $line | grep -q -E '\<nsGkAtoms\>' || sed -i -e '/nsGkAtoms.h/d' $line ; done
Differential Revision: https://phabricator.services.mozilla.com/D292697
Having two lists that the frame constructor is not aware is a quirk that
causes correctness issues like bug 2021043.
Instead, sort rowgroups and colgroups once in the common case during
table layout. This also fixed some visibility collapse things because
now we compute overflow just once after collapsing. It also caused some
unexpected passes in some editing tests.
Add a test for bug 2021043, which is fixed by this.
Differential Revision: https://phabricator.services.mozilla.com/D286457
We already rely on one frame having at most one
absolute list, so there's no point in this distinction.
In the future, with position-visibility, we might want
to make fixed and abspos containing block effectively the same.
But one step at a time.
Differential Revision: https://phabricator.services.mozilla.com/D282681
This patch consists of several parts:
- Introduce `PushedAbsolute` frame list (i.e. `mPushedAbsoluteFrames`) in
AbsoluteContainingBlock. This list is a temporary list used during reflow,
to store abspos frames that need to be reflowed by the delegating frame's
next-in-flow.
- For an absolute containing block frame, ensure its continuations also have
absolute containing block.
- Ensure that the position of abspos continuation is correct by adjusting
border, available block-size, etc. in
`AbsoluteContainingBlock::ReflowAbsoluteFrame()`.
- Cache `layout.abspos.fragmentainer-aware-positioning.enabled` pref at the time
when `nsPresContext` is initialized such that the pref value is stable across
the lifetime of `nsPresContext`. This is to ensure the frame tree structure
hygiene.
Differential Revision: https://phabricator.services.mozilla.com/D272400
This patch consists of several parts:
- Introduce `PushedAbsolute` frame list (i.e. `mPushedAbsoluteFrames`) in
AbsoluteContainingBlock. This list is a temporary list used during reflow,
to store abspos frames that need to be reflowed by the delegating frame's
next-in-flow.
- For an absolute containing block frame, ensure its continuations also have
absolute containing block.
- Ensure that the position of abspos continuation is correct by adjusting
border, available block-size, etc. in
`AbsoluteContainingBlock::ReflowAbsoluteFrame()`.
- The change in `nsPresContext` is to force reconstruct frame tree when flipping
`layout.abspos.fragmentainer-aware-positioning.enabled` pref, to ensure frame
tree structure hygiene.
Differential Revision: https://phabricator.services.mozilla.com/D272400
This fixes the issue by moving the table captions to the principal child
list. It also paves the way to fix bug 144517, but it doesn't fix it as
that requires extra layout changes to nsTableWrapper frame (mostly to
reserve the multiple caption block sizes).
Test courtesy of Masayuki in D246407 (with minor tweaks).
Differential Revision: https://phabricator.services.mozilla.com/D246468
Bug 729519 [1] made the empty frame list be allocated in the
`.rodata` (read-only) section. However, the setup can be simplified.
To verify that `sEmptyList` is still allocated in the `.rodata` section, I used
the following steps on my local Linux build:
1. Move `nsFrameList.cpp` in moz.build from UNIFIED_SOURCES to SOURCES.
2. Run `./mach build`.
3. Run `objdump -x $(OBJDIR)/layout/generic/nsFrameList.o | grep sEmptyList`.
4. Verify that the output `sEmptyList` has `.rodata`. The objdump output looks
like this:
```
0000000000000038 g O .rodata 0000000000000010 .hidden _ZN11nsFrameList10sEmptyListE
```
[1] Specifically, this commit:
https://hg.mozilla.org/mozilla-central/rev/c320c5821f98
Differential Revision: https://phabricator.services.mozilla.com/D214226
With only the Part 1, `layout/generic/crashtests/1683126.html` will timeout.
It can be reproduced locally via
```
./mach crashtest layout/generic/crashtests/1683126.html
```
It is because if we destroy a frame list from the first child to the last child,
each time we destroy the first child [1], the second child become the new first
child, and we have to update the first-in-flow and first-continuation cache for
later continuations, which is a linear time operation.
[1] See nsSplittableFrame::RemoveFromFlow() with the argument being the first
child in a frame list.
Differential Revision: https://phabricator.services.mozilla.com/D197967
With only the Part 1, `layout/generic/crashtests/1683126.html` will timeout.
It can be reproduced locally via
```
./mach crashtest layout/generic/crashtests/1683126.html
```
It is because if we destroy a frame list from the first child to the last child,
each time we destroy the first child [1], the second child become the new first
child, and we have to update the first-in-flow and first-continuation cache for
later continuations, which is a linear time operation.
[1] See nsSplittableFrame::RemoveFromFlow() with the argument being the first
child in a frame list.
Differential Revision: https://phabricator.services.mozilla.com/D197967
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
The removed SetFrames() is slow (it traverses the next sibling chain to find the
last sibling) and has only one caller. Let's remove it.
The rewrite in nsInlineFrame::PullOneFrame() doesn't change behavior because
`frame` is just removed from the overflow list, so it won't have any next
sibling. We are creating a frame list containing only `frame`.
Differential Revision: https://phabricator.services.mozilla.com/D160839
RemoveFramesAfter and ExtractTail have similar purpose, so we really should keep
one of them to avoid confusion.
They have the following minor differences:
1. RemoveFramesAfter() keeps aFrame in the list, while ExtractTail() returns it.
2. If aFrame is empty, RemoveFramesAfter() returns the entire list, while
ExtractTail returns an empty list.
It's more convenient for the existing callers to use the RemoveFramesAfter(), so
ExtractTail is unneeded.
After this patch, both RemoveFramesAfter() and RemoveFramesBefore() return the
entire list if aFrame is nullptr.
Rename RemoveFramesAfter() to TakeFramesAfter() for symmetry with
TakeFramesBefore().
This change shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D158807
I feel it's hard to understand the purpose of ExtractHead(), especially where
aFrame is going after the call. Therefore, I rename it to TakeFramesBefore(),
and have it complement the existing RemoveFramesAfter(), which will be rename
later. No behavioral change intended.
Also, slightly reword the method's documentation to reflect the its new
name. (Remove the "sibling" wording from the comment since it's an
implementation details that frames are actually a doubly linked list.)
Differential Revision: https://phabricator.services.mozilla.com/D158806
This is a preparation to remove nsFrameList::FrameLinkEnumerator in the next
part.
FrameLinkEnumerator::Find() can be replaced with std::find/std::find_if.
Differential Revision: https://phabricator.services.mozilla.com/D158700
AutoFrameListPtr might be used more frequently after we add more APIs to
handle overflow container list and excess overflow container list in
bug 1641085.
The improvements in this patch includes:
* Mark AutoFrameListPtr as MOZ_RAII and final class.
* Move AutoFrameListPtr into mozilla namespace since we don't use layout
sub-namespace that much these days.
* Remove the AutoFrameListPtr type alias in nsGridContainerFrame's
header since it's not used.
Differential Revision: https://phabricator.services.mozilla.com/D77568
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
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
serge-sans-paille