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
This reverts commit 88008cd8ca.
Revert "Bug 2012637 - part 8: Make `nsContentUtils::ComparePoints` handle `TreeKind::Flat` and `TreeKind::FlatForSelection` correctly r=smaug,dom-core"
This reverts commit 73e6f6587b.
Revert "Bug 2012637 - part 7: Make `RangeUtils::CompareNodeToRangeBoundaries()` use `nsContentUtils::ComparePoints` with valid point in the tree r=smaug"
This reverts commit 6985d5e80f.
Revert "Bug 2012637 - part 6: Make `nsRange::CutContents()` convert the range boundaries to the ones in the DOM before comparing r=smaug"
This reverts commit 73b585af3d.
Revert "Bug 2012637 - part 5: Delete the default template parameter of `nsContentUtils::ComparePoints` and relatives r=smaug,dom-core"
This reverts commit 1a7f24e5b5.
Revert "Bug 2012637 - part 4: Make `nsContentUtils` use `nsIContent` for taking a child node as a parameter r=smaug"
This reverts commit a6ea8d6824.
Revert "Bug 2012637 - part 3: Add template `nsINode` API which can switch to call API from `TreeKind` r=smaug,dom-core,webidl"
This reverts commit a4211e9df0.
Revert "Bug 2012637 - part 2: Add `TreeKind::FlatForSelection` and change the template parameter of `ChildIteratorBase` to `TreeKind` r=smaug,dom-core"
This reverts commit 0241749ee7.
Revert "Bug 2012637 - part 1: Make `ChildIterBase` template class to re-implement `FlattenedChildIterator` for DOM, Flat and FlatForSelection TreeKind r=smaug,dom-core,layout-reviewers,emilio"
This reverts commit 9e71cb77fb.
This will make the main patch simpler. However, some of them do not
support `TreeKind::ShadowIncludingDOM` because it's unclear what
should return as a parent node of a child of `ShadowRoot`, what should
return as a child node of a shadow host. To avoid the developers to use
them on wrong assumptions, this patch makes the users use `DOM`, `Flat`
or `FlatForSelection` explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D281305
That is, after this patch, the BRFrame's inline-size becomes zero.
This patch is based on the previous attempt [1] in this bug, and removes the
code added in Bug 1242781.
The test_bug1216483.html change is worth an explanation. Each sub-test verifies
the blinking cursor (caret) position after pressing down arrow key in an
contenteditable container. The expected position is to the right of the letter
"a". Before this patch, the `(anchorNode, anchorOffset)` was
`("element with '.second' style", 1)`. After this patch, it becomes
`("a", 1)`, which is a valid representation of the caret position and
matches Google Chrome's behavior.
[1] https://hg.mozilla.org/mozilla-central/rev/c3f1ab75ea51
Differential Revision: https://phabricator.services.mozilla.com/D238162
That is, after this patch, the BRFrame's inline-size becomes zero.
This patch is based on the previous attempt [1] in this bug, and removes the
code added in Bug 1242781.
The test_bug1216483.html change is worth an explanation. Each sub-test verifies
the blinking cursor (caret) position after pressing down arrow key in an
contenteditable container. The expected position is to the right of the letter
"a". Before this patch, the `(anchorNode, anchorOffset)` was
`("element with '.second' style", 1)`. After this patch, it becomes
`("a", 1)`, which is a valid representation of the caret position and
matches Google Chrome's behavior.
[1] https://hg.mozilla.org/mozilla-central/rev/c3f1ab75ea51
Differential Revision: https://phabricator.services.mozilla.com/D238162
This patch is based on the previous attempt [1] in this bug, and removes the
code added in Bug 1242781.
The test_bug1216483.html change is worth an explanation. Each sub-test verifies
the blinking cursor (caret) position after pressing down arrow key in an
contenteditable container. The expected position is to the right of the letter
"a". Before this patch, the `(anchorNode, anchorOffset)` was
`("element with '.second' style", 1)`. After this patch, it becomes
`("a", 1)`, which is a valid representation of the caret position and
matches Google Chrome's behavior.
[1] https://hg.mozilla.org/mozilla-central/rev/c3f1ab75ea51
Differential Revision: https://phabricator.services.mozilla.com/D238162
If `position` of `<br>` is `fixed`, its parent frame is only the viewport
frame, thus, no block frame ancestors causing
`nsBlockFrame::GetNearestAncestorBlock` runs the unreachable case.
Therefore, if the parent frame of the `BRFrame` is a viewport frame, it should
return `a11y::eHTMLBRType` as treating itself as a normal `<br>` rather than
a padding `<br>` element.
Differential Revision: https://phabricator.services.mozilla.com/D237173
Currently, it returns `a11y::eNoType` when the content is marked as a padding
line break which is for either empty editor in the document level or empty
last line immediately before a block boundary. However, by the previous patch,
`<br>` element will have the "padding `<br>` for the last empty line" strictly.
The padding `<br>` elements are basically meaningless. However, it may be
meaningful only in some edge cases.
In the former case, the `<br>` is always put in empty `<body>` and the `<body>`
may have both before and after pseudo elements. Therefore, it should always be
treated as a normal `<br>`. Otherwise, the generated content will be treated
as one word.
In the latter case, there are 3 cases:
1. following another line break to make the empty line visible
2. following a block boundary to make the empty line between block boundaries
visible
3. following a visible content due to a bug of our editor
At least, the method should not treat the `<br>` as meaning in the #2 case
because it may split the before and after pseudo elements' content of the parent
block.
Therefore, this patch takes care of only the 2nd case as a normal `<br>`.
Differential Revision: https://phabricator.services.mozilla.com/D232892
And don't resolve them prematurely; the computed value should remain
logical, and only be mapped to physical sides at use time.
Differential Revision: https://phabricator.services.mozilla.com/D229998
And don't resolve them prematurely; the computed value should remain
logical, and only be mapped to physical sides at use time.
Differential Revision: https://phabricator.services.mozilla.com/D229998
The two macros are used in `GetPrefISize()` and `GetMinISize()` implementations.
After removing them, we could further simplify some implementations because we
don't need a `result` variable in many cases.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D206316
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Before, there existed 3 virtual functions that calculated baselines:
- `GetLogicalBaseline`
- `GetVerticalAlignBaseline`
- `GetNaturalBaselineBOffset`
Each of them had slightly different behaviours:
- `GetLogicalBaseline` would synthesize a baseline if there is no baseline.
Others would simply return `false`.
- `GetNaturalBaselineBOffset` requires the caller to pick which of first/last
baseline to calculate. Others pick on on their own.
- `GetNaturalBaselineBOffset`'s result can be either offset from border box
start/end edge, depending on the caller-supplied baseline. Others always
return offset from border box start edge.
Now:
- `GetNaturalBaselineBOffset` is the sole virtual function.
- `GetLogicalBaseline` exists to support its use, with 2 virtual helper functions:
- `SynthesizeFallbackBaseline` to generate a baseline for elements that
doesn't have one.
- `GetBaselineSharingGroup` to preserve the default baseline picking behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D167990
* Rename `mBreakType` to `mFloatClearType` in nsLineBox and nsReflowStatus and
the methods around it.
* Rename `mBreakType` to `mClear` in nsStyleDisplay.
* Many other method parameters or local variables rename such as from
`aBreakType` to `aClearType`.
Differential Revision: https://phabricator.services.mozilla.com/D158276
Before this patch, StyleClear::Line indicates that the nsLineBox has break-after
but no float clearance (note we don't allow line break-before with clear:none);
StyleClear::None indicates the line has no break-before nor break-after.
In this patch, I added `mHasForcedLineBreak` bit in nsLineBox to indicate the
line has a break so that StyleClear can serve its original meaning -- the float
clearance. In Part 6, I'll rename more existing methods and variables related to
float clearance.
Now, instead of using StyleClear::None to clear the line break status, the
caller should use ClearForcedLineBreak(); Similar to set
SetInlineLineBreakBeforeAndReset() and SetInlineLineBreakAfter on
nsReflowStatus, SetBreakTypeBefore/SetBreakTypeAfter on nsLineBox always sets
break status with an optional float clearance parameter.
This patch shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D158224
Override GetFrameName() for BRFrame so that frame tree dump shows `BR(br)`
rather than `Frame(br)`.
Also, expand nsLineBox::StateToString() in List() to get rid of `cbuf`.
Differential Revision: https://phabricator.services.mozilla.com/D158111
Remove `virtual` for methods already having `override`. Remove `explicit` for
the constructor because it has two parameters.
Differential Revision: https://phabricator.services.mozilla.com/D158109
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
Seva Alipov