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
I checked the history, the assert has been commented out since 2000, it was added in 1999. It doesn't seem useful, all the callers basically just get the parent view right before the call.
Differential Revision: https://phabricator.services.mozilla.com/D177862
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
We had these spread around, it's better to have a single central place where we
update the widget based on the styling of the popups.
Differential Revision: https://phabricator.services.mozilla.com/D173836
We still have some remnants of XUL layout due to nsBox / nsLeafBoxFrame
which XUL trees / nsTextBoxFrame still use.
However all this code can go away before we get rid of those.
nsSplitterFrame was the last thing inheriting from nsBoxFrame.
Differential Revision: https://phabricator.services.mozilla.com/D173601
The a11y module wants to traverse frames in native anonymous subtrees.
Therefore, this patch adds new option for allowing it, makes
`nsIFrame::GetFrameFromDirection` check it before comparing native anonymous
subtree root nodes, and makes `HyperTextAccessible::FindOffset` use the
option.
Differential Revision: https://phabricator.services.mozilla.com/D172759
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
It's called by `PeekOffsetFor*` and `GetPrevNextBidiLevels`, so it's used for
considering whether to put caret or move a selection range boundary.
Therefore, it should treat nodes which can be managed by `Selection` as
selectable. In theory, even if a native anonymous subtree does not have
an independent selection, its content nodes should not be the container of
the selection range boundaries of selection outside the subtree since
Selection API shouldn't expose nodes in native anonymous subtrees. Therefore,
it can simply treat content nodes in different anonymous subtrees are not
selectable.
Note that it's not standardized that how `Selection.modify` works with various
content nodes.
https://w3c.github.io/selection-api/#dom-selection-modify
And also Chrome cannot cross generated content like form controls with this API.
This could cause web-compat issues, but it does not make sense for caret
navigation, and anyway out of scope of this bug. Therefore, this patch just
adds the crash test.
Differential Revision: https://phabricator.services.mozilla.com/D172204
The a11y module wants to traverse frames in native anonymous subtrees.
Therefore, this patch adds new option for allowing it, makes
`nsIFrame::GetFrameFromDirection` check it before comparing native anonymous
subtree root nodes, and makes `HyperTextAccessible::FindOffset` use the
option.
Differential Revision: https://phabricator.services.mozilla.com/D172759
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
It's called by `PeekOffsetFor*` and `GetPrevNextBidiLevels`, so it's used for
considering whether to put caret or move a selection range boundary.
Therefore, it should treat nodes which can be managed by `Selection` as
selectable. In theory, even if a native anonymous subtree does not have
an independent selection, its content nodes should not be the container of
the selection range boundaries of selection outside the subtree since
Selection API shouldn't expose nodes in native anonymous subtrees. Therefore,
it can simply treat content nodes in different anonymous subtrees are not
selectable.
Note that it's not standardized that how `Selection.modify` works with various
content nodes.
https://w3c.github.io/selection-api/#dom-selection-modify
And also Chrome cannot cross generated content like form controls with this API.
This could cause web-compat issues, but it does not make sense for caret
navigation, and anyway out of scope of this bug. Therefore, this patch just
adds the crash test.
Differential Revision: https://phabricator.services.mozilla.com/D172204
The a11y module wants to traverse frames in native anonymous subtrees.
Therefore, this patch adds new option for allowing it, makes
`nsIFrame::GetFrameFromDirection` check it before comparing native anonymous
subtree root nodes, and makes `HyperTextAccessible::FindOffset` use the
option.
Depends on D172758
Differential Revision: https://phabricator.services.mozilla.com/D172759
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
It's called by `PeekOffsetFor*` and `GetPrevNextBidiLevels`, so it's used for
considering whether to put caret or move a selection range boundary.
Therefore, it should treat nodes which can be managed by `Selection` as
selectable. In theory, even if a native anonymous subtree does not have
an independent selection, its content nodes should not be the container of
the selection range boundaries of selection outside the subtree since
Selection API shouldn't expose nodes in native anonymous subtrees. Therefore,
it can simply treat content nodes in different anonymous subtrees are not
selectable.
Note that it's not standardized that how `Selection.modify` works with various
content nodes.
https://w3c.github.io/selection-api/#dom-selection-modify
And also Chrome cannot cross generated content like form controls with this API.
This could cause web-compat issues, but it does not make sense for caret
navigation, and anyway out of scope of this bug. Therefore, this patch just
adds the crash test.
Differential Revision: https://phabricator.services.mozilla.com/D172204
It's called by `PeekOffsetFor*` and `GetPrevNextBidiLevels`, so it's used for
considering whether to put caret or move a selection range boundary.
Therefore, it should treat nodes which can be managed by `Selection` as
selectable. In theory, even if a native anonymous subtree does not have
an independent selection, its content nodes should not be the container of
the selection range boundaries of selection outside the subtree since
Selection API shouldn't expose nodes in native anonymous subtrees. Therefore,
it can simply treat content nodes in different anonymous subtrees are not
selectable.
Note that it's not standardized that how `Selection.modify` works with various
content nodes.
https://w3c.github.io/selection-api/#dom-selection-modify
And also Chrome cannot cross generated content like form controls with this API.
This could cause web-compat issues, but it does not make sense for caret
navigation, and anyway out of scope of this bug. Therefore, this patch just
adds the crash test.
Differential Revision: https://phabricator.services.mozilla.com/D172204
See comments in the bug, which still stand.
This cache is barely hit, and when it is hit it causes correctness
issues, see bug 1815022 for a recent example.
Differential Revision: https://phabricator.services.mozilla.com/D171391
While looking at the backout, I noticed table parts relied on reframing
on abspos-container-ness changes in a subtle way, see the test, which
fails with the first patch of this bug applied without these changes.
Make the NS_FRAME_CAN_HAVE_ABSPOS_CHILDREN mean the same for table parts
as for everything else. Instead, keep the registration status on each
relevant frame class individually.
Depends on D169127
Differential Revision: https://phabricator.services.mozilla.com/D170969
While looking at the backout, I noticed table parts relied on reframing
on abspos-container-ness changes in a subtle way, see the test, which
fails with the first patch of this bug applied without these changes.
Make the NS_FRAME_CAN_HAVE_ABSPOS_CHILDREN mean the same for table parts
as for everything else. Instead, keep the registration status on each
relevant frame class individually.
Depends on D169127
Differential Revision: https://phabricator.services.mozilla.com/D170969
Callers of `GetCaretBaseline` just use it to get offset and size of the caret, so
refactor the shared logic. In the call sites, delay conversion of logical to physical
rect to reduce variable shuffling.
Differential Revision: https://phabricator.services.mozilla.com/D169210
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
We were ignoring print backgrounds, but still darkening colors, which
obviously breaks.
I tracked this down to bug 191574 /
https://searchfox.org/mozilla-central/commit/0757c0a5b18b646554969a67eedf2bcb0ad41b63
> Make sure all caller have to pass in the "ignore 'print backgrounds'
> Make block/inline _not_ ignore that pref
Which was just preserving behavior. So this seems all rather accidental.
Implement backgrounds for page / page sequence frame using
print-color-adjust, and remove the virtual method.
The XUL box removal stuff seems harmless. The only XUL boxes we have
around in content are scrollbars, and we don't have scrollbars when
printing.
Differential Revision: https://phabricator.services.mozilla.com/D168382
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
