It was made pointless by the previous patch.
This replaces callers that had a frame type for another reason with the
frame type check that IsTableCell did, and callers that needed to call
Type() with an IsTableCellFrame call.
Differential Revision: https://phabricator.services.mozilla.com/D40561
--HG--
extra : moz-landing-system : lando
This also renames the existing infallible nsDocShell:GetBrowsingContext()
getter to BrowsingContextRef(), and changes the return type, since several
callers rely on it returning a raw pointer rather than an already_AddRefed.
Differential Revision: https://phabricator.services.mozilla.com/D40312
--HG--
extra : moz-landing-system : lando
nsTypeAheadFind.cpp contains all of the callsites to this function, so it seems like a logical place for it to live.
Differential Revision: https://phabricator.services.mozilla.com/D40696
--HG--
extra : moz-landing-system : lando
We want mHasColumnSpanSiblings to propagate to all the
continuations (both fixed ones or fluid ones) in nsFrame::Init() so that
we don't need to traverse all the way to FirstInFlow() for the bit in
nsBlockFrame::ComputeFinalBSize().
For the last ColumnSet or the last non-column-span wrapper, we'll need
to unset the bit for them manually after constructing them.
Differential Revision: https://phabricator.services.mozilla.com/D40761
--HG--
extra : moz-landing-system : lando
We naively remove and then recreate accessibles when their content's
frame is reconstructed. By delaying the removal until we are certain the
content does not have a new layout frame, we can cut down on redundant
recreations.
When reconstructed content is re-inserted we can check it and its
subtree for missing frames and prune those accessibles from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D38380
--HG--
extra : moz-landing-system : lando
These frame state bits belong to the generic group, and there is
existing logic in nsFrame::Init() for carrying frame state bits. It's
better to consolidate them in one place.
Differential Revision: https://phabricator.services.mozilla.com/D40244
--HG--
extra : moz-landing-system : lando
Not happy with all these void pointer stuff, but I think this is slightly nicer
to read.
Also not happy with what clang-format has done to my code ;)
I've removed the comment about zoom because it's not clear to me it is still
relevant, but I've preserved the order because, should we have similar stuff
going on, it seems slightly better, and I'm moderately sure the rest of the
callers don't really care.
I think closures coerced to function pointers are nicer (I considered putting
this on a template or using std::function, maybe, this was less code specially
given some callers of EnumerateExternalResources may or may not be hot...),
but if you want me to keep stuff out of line, or move the whole thing to
std::function<> or templates let me know.
Differential Revision: https://phabricator.services.mozilla.com/D40249
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
--HG--
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-001.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-002.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-span-all-rule-001.html.ini
extra : moz-landing-system : lando
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
--HG--
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-001.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-002.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-span-all-rule-001.html.ini
extra : moz-landing-system : lando
Also spam a NS_ERROR whenever this happens (in debug builds), so that we
know to fix the caller to avoid division by zero.
Differential Revision: https://phabricator.services.mozilla.com/D39801
--HG--
extra : moz-landing-system : lando
In frame construction, a block can be split by column-spans into several
fragments and each of the fragments is chained together by non-fluid
continuations. Later in reflow, each fragment can create its own fluid
continuations due to reasons such as the constraint of its available
block-size.
The main idea of this patch is that we calculate the block's final
block-size by shrinkwrapping the children for every fragment except for
those fluid continuations after the final column-span. To do that, we
need to correctly tag each non-column-span-wrappers
nsIFrame::HasColumnSpanSiblings() except the last one.
We also need to modify nsSplittableFrame::ConsumedBSize() so that it
includes the block-size for both fluid and non-fluid continuations.
Differential Revision: https://phabricator.services.mozilla.com/D38124
--HG--
extra : moz-landing-system : lando
When privacy.spoof_english = 2, we should hide the user's
locale in content. So we use en-US default strings for HTML
form elements, such as a Submit button.
We also force GetLocalizedEllipsis() to always return the
ellipsis used by en-US.
Differential Revision: https://phabricator.services.mozilla.com/D35815
--HG--
extra : moz-landing-system : lando
One of the issues with the test-case in this bug is that the page consumes a ton
of CPU due to scroll anchor adjustments being triggered from scroll events,
which in turn cause other scroll events to fire.
This happens in Chrome as well (just scroll to the bottom of the test-case, and
do `addEventListener("scroll", () => console.log("scroll"))` on devtools. But I
think it's worth fixing. This patch fixes it and overall I think it's a slightly
better approach to suppress adjustments than what we're doing.
Differential Revision: https://phabricator.services.mozilla.com/D39339
--HG--
extra : moz-landing-system : lando
If the subdocument display item gets created when the subdocument doesn't have a root frame it'll be based on the subdocument frame in the parent document. This means that the prescontext pointer on the document viewer of the subdocument can go away without the subdocument display item getting any kind of invalidation. So we make sure the subdocument display item gets rebuilt if that happens. The reason the prescontext pointer is important is that is what nsSubDocumentFrame::GetSubdocumentPresShellForPainting uses (via nsDocShell::GetPresShell) to get the subdocument presshell. So it will fail to get a presshell and RetainedDisplayListBuilder::IncrementSubDocPresShellPaintCount will crash.
Differential Revision: https://phabricator.services.mozilla.com/D39310
--HG--
extra : moz-landing-system : lando
When we use SVG layout, and transform-box is fill-box, the current
implementation makes the object not align with offset-path because there
may be an offset (SVG x and y values) between the anchor point and offset-path.
We have to tweak the anchor point to fix the alignment.
Differential Revision: https://phabricator.services.mozilla.com/D39419
--HG--
rename : testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box.html => testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box-001.html
rename : testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box.html => testing/web-platform/tests/css/motion/offset-anchor-transform-box-fill-box-002.html
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
For a slow tick, where the processing time takes longer than 1/60th sec, record
telemetry for the percentage of that time spent in each sub-system processing
Events, Style), Reflow, Display and Paint.
Differential Revision: https://phabricator.services.mozilla.com/D38962
--HG--
extra : moz-landing-system : lando
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
--HG--
extra : moz-landing-system : lando
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
--HG--
extra : moz-landing-system : lando
L. David Baron
Nika Layzell
Kris Maglione
Emilio Cobos Álvarez
Ting-Yu Lin
Tom Schuster
Edgar Chen
Cosmin Sabou
Razvan Maries
Nicholas Nethercote
Botond Ballo
Eitan Isaacson
Boris Chiou
Brindusan Cristian
Olli Pettay
Ciure Andrei
Daniel Holbert
Alex Catarineu
Timothy Nikkel
Kannan Vijayan
Andreea Pavel
Daniel Varga
Dan Glastonbury
Coroiu Cristina