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
We fail some because we right now we have a track pseudo for meter/progress.
I plan to fix this, but a lot of these frame classes are basically copy-pasta,
so I wanted to get rid of them first.
Differential Revision: https://phabricator.services.mozilla.com/D192097
These only paint inner box shadows and borders, both of which we support with
WR display items, so we probably never hit fallback rendering for this and don't
call this method. But in case we do, it should be fine to use blob rendering
for it these days.
Depends on D188490
Differential Revision: https://phabricator.services.mozilla.com/D188491
In practice, this is only ever true on the native windows theme. All
other themes return true for ThemeDrawsFocusForWidget for Button and
Menulist, which are the relevant appearance values here. So make this
more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D187856
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
Calling `UpdateDefaultPreventedOnContent` separately from
`PreventDefault()` is error-prone. This patch should make it
safer.
Differential Revision: https://phabricator.services.mozilla.com/D186052
Tests are added as tentative, because the behaviour when there's no content,
or when there's placeholder text, seem very differnt for each browser.
Differential Revision: https://phabricator.services.mozilla.com/D185958
Tests are added as tentative, because the behaviour when there's no content,
or when there's placeholder text, seem very differnt for each browser.
Differential Revision: https://phabricator.services.mozilla.com/D185958
This patch introduces functional pseudo parameters, i.e. `::highlight(foo)`,
for `getComputedStyle()`. This required adapting the parse algorithm (`nsCSSPseudoElements::ParsePseudoElement()`) and forwarding the functional pseudo parameter into the style engine.
Differential Revision: https://phabricator.services.mozilla.com/D183773
This allows us to deprecate `mozInputSource` for the Web while
avoiding console warnings for internal uses, which now use the
ChromeOnly `inputSource` attribute.
Differential Revision: https://phabricator.services.mozilla.com/D183643
It is always called from TextControlState, and always ends up in
TextControlState::ValueEquals, so we can avoid some indirection and just
use that.
Depends on D183282
Differential Revision: https://phabricator.services.mozilla.com/D183283
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
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
This is somewhat arbitrary, as the behavior of the 'size' attribute is not clearly specified
for non-fixed-width fonts where "character width" is a vague concept. So there's no absolute
"right" or "wrong" result, but there are cases where our current behavior feels quite wrong
to authors.
There are two adjustments here that aim to make the behavior more consistent and predictable.
First, rather than using the font's "average" char width (which is itself not a clearly-
defined or reliably-set metric) as the basic multiplier for the 'size' attribute, prefer
to use the width of the zero glyph (0), if present. This makes size-attribute-based input
fields behave more consistently with fields sized using the CSS 'ch' unit, rather than
having apparently-random inconsistencies between the two.
Second, the existing code adds a "padding" factor based on the font's maxAdvance, but this
can be quite excessive with modern fonts, where there may be outliers such as logo glyphs
or long ligatures that are much wider than typical characters. E.g. the macOS system font
has a triple-em-dash ligature; or the Ubuntu font, which declares an advanceWidthMax of
3511 units, although the widest glyph I can find is the "ffl" ligature with a width of 1053
units.
To limit the effect that such outliers (or incorrect metadata) can have, I'm proposing to
clamp the "max" width that we use here to twice the "char width" derived from the zero glyph
or the font's declared average. So we're still doing the "IE-like" addition of some extra
width when using non-fixed-space fonts, but it won't become as huge as it currently does
in some cases (depending on font details).
Differential Revision: https://phabricator.services.mozilla.com/D176922
Emilio Cobos Álvarez
Tom Marble
Jan Varga
Markus Stange
Ting-Yu Lin
Narcis Beleuzu
Olli Pettay
Sean Feng
David Shin
Iulian Moraru
Masayuki Nakano
Cristian Tuns
Jan-Niklas Jaeschke
Mathew Hodson
Jonathan Kew
Noemi Erli
Kershaw Chang
Norisz Fay
Sandor Molnar