DONTBUILD because this is a comment-only change.
Per bug 1481951 comment 6, it seems our behavior was in fact correct even when
the comment was added, and this "// XXX" comment was just due to a
misunderstanding in what was going on in the testcase.
Differential Revision: https://phabricator.services.mozilla.com/D44229
--HG--
extra : moz-landing-system : lando
This also fixes some of the issues with -moz-image-region, where we just minted
an auto out of the blue.
Depends on D43472
Differential Revision: https://phabricator.services.mozilla.com/D43474
--HG--
extra : moz-landing-system : lando
This patch is auto-generated by the following command:
./mach clang-format -p layout/
Differential Revision: https://phabricator.services.mozilla.com/D42218
--HG--
extra : moz-landing-system : lando
Converts layout.css.outline-style-auto.enabled to a static pref and removes nsLayoutUtils::isOutlineStyleAutoEnabled().
Differential Revision: https://phabricator.services.mozilla.com/D41861
--HG--
extra : moz-landing-system : lando
It seems better to convert this before adding a new flag (in bug
1547759) and risking replacing the wrong 0 with a flag.
Differential Revision: https://phabricator.services.mozilla.com/D40562
--HG--
extra : moz-landing-system : lando
There are two existing callers of IsTableCellFrame that both appear to want to
include BCTableCell frames, but don't. A patch in bug 1547759 will add a
third that wants the same.
The existing users of frame types all have to work around it being a distinct
type, and none appear to want the distinction. This removes that complexity.
If any callers want to make the distinction, they could implement QueryFrame
for BCTableCellFrame and use it. (It's not implemented now, though!)
In a little more detail, prior to this patch (in my debug build, at least):
* nsQueryFrame::ClassID::nsMathMLmtdFrame_id was 46
* nsQueryFrame::ClassID::nsTableCellFrame_id was 47
* nsQueryFrame::ClassID::nsBCTableCellFrame_id was 65
and entries 46 and 47 in sLayoutFrameTypes were
mozilla::LayoutFrameType::TableCell while entry 65 was
mozilla::LayoutFrameType::BCTableCell.
With this patch:
* nsQueryFrame::ClassID::nsBCTableCellFrame_id is 40
* nsQueryFrame::ClassID::nsMathMLmtdFrame_id is 41
* nsQueryFrame::ClassID::nsTableCellFrame_id is 42
and entries 40 through 42 in sLayoutFrameTypes are
mozilla::LayoutFrameType::TableCell.
Differential Revision: https://phabricator.services.mozilla.com/D40560
--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
After moving the logic that carries NS_FRAME_OUT_OF_FLOW bit from the
prev-in-flow into nsFrame::Init() in Part 1,
testing/web-platform/tests/css/css-multicol/float-and-block.html starts
to crash.
In the test, it has a float element that fragments into two columns.
When creating a continuation for the float frame, we have a callstack
looks like nsFrame::Init() -> UpdateVisibleDescendantsState() ->
GetInFlowParent(). Because NS_FRAME_OUT_OF_FLOW is set in
nsFrame::Init(), GetInFlowParent() tries to get
PlaceholderFrameProperty() on its FirstContinuation(), but the first
continuation is not established until the end of
nsCSSFrameConstructor::CreateContinuingFrame().
This being said, we don't need to UpdateVisibleDescendantsState() when
creating continuations because UpdateVisibleDescendantsState() needs to
traverse a stable frame tree, and the animation code only looks at the
primary frames.
Differential Revision: https://phabricator.services.mozilla.com/D40245
--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
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
This reduces a bit of code complexity, fixes bugs where we weren't
reflowing enough, and optimizes additional cases that we couldn't
optimize in the past.
Co-authored-by: Chris Pearce <cpearce@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Differential Revision: https://phabricator.services.mozilla.com/D37610
--HG--
extra : moz-landing-system : lando
This simplifies dealing with frames that are pushed/pulled between
continuations during reflow, allows us to avoid the complexity of the
fix to 1459937, and hopefully fixes some of the regressions from bug
1308876.
This disables the changes from bug 1459937 by commenting out a single
line in ReparentFrameInternal in nsBlockFrame.cpp, but all the added
code will be removed in the following patch.
Co-authored-by: Gerald Squelart <gsquelart@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Depends on D36423
Differential Revision: https://phabricator.services.mozilla.com/D36424
--HG--
extra : moz-landing-system : lando
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
--HG--
extra : moz-landing-system : lando
The arguments for the respective container elements apply to their immediate
child items, too: They establish a new formatting context as well and presumably
represent page content that can be considered to be logically separate enough to
warrant individual consideration for font inflation.
Differential Revision: https://phabricator.services.mozilla.com/D35881
--HG--
extra : moz-landing-system : lando
This is a rework for the issue in bug 1516963.
The condition `aFrame->IsFrameOfType(nsIFrame::eReplaced)` was added to
avoid breaking
editor/libeditor/tests/test_abs_positioner_positioning_elements.html
because it contains blockified (position:absolute) images in
contenteditable, and we don't want these images to use frame edge. But
for non-editable undraggable images, which have display:inline, we want
them to use frame edge to avoid being selected by a single-clicking.
Note that non-editable draggable images use a different code patch to
handle their operations.
I think it easier to understand by checking the frame types directly. As
for images, we want non-editable images to use frame edge, but not those
editable ones because editor has its own logic to handle all the
dragging operations, etc. Using frame edge for editable images makes
them undraggable, and fails
test_abs_positioner_positioning_elements.html.
Add more tests for empty inline-grid, inline-flex, inline-table, video,
to ensure the behavior is not changed. We don't want them to be selected
by a single-clicking, either.
Note I only test video's selection is collapsed when single-clicking
because I failed to turn off picture-in-picture on <video> in
test_reftests_with_caret.html.
Differential Revision: https://phabricator.services.mozilla.com/D34909
--HG--
extra : moz-landing-system : lando
I _think_ most of the sizes that get here are going to be equivalent to
mRect.Size(), but that seems really hard to prove.
Differential Revision: https://phabricator.services.mozilla.com/D32754
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This should be an idempotent patch. The way to come up with this patch has been:
* Run the first script attached to the bug and pipe it to xclip, then paste it
in color.rs
* Add the relevant #[derive] annotations and remove the color.mako.rs
definition.
* Reorder the values to match the ColorID definition, on which some widget
prefs and caching stuff relies on.
* Manually port some documentation from nsLookAndFeel.h
* Run `rg 'eColorID_' | cut -d : -f 1 | sort | uniq >files`
* Run the second script attached to the bug.
* Manually fix usage of `LAST_COLOR` (adding the `End` variant), and adding
casts to integer as needed.
* Add an static assert so that people remember to update the prefs, rather than
a comment on the definition :)
Differential Revision: https://phabricator.services.mozilla.com/D32610
--HG--
extra : moz-landing-system : lando
Daniel Holbert
Emilio Cobos Álvarez
Cameron McCormack
Connor Brewster
Kristen Wright
Mats Palmgren
L. David Baron
Ting-Yu Lin
Botond Ballo
Nicholas Nethercote
Dan Glastonbury
longsonr
Bogdan Tara
Mirko Brodesser
Chris Pearce
Gerald Squelart
Cosmin Sabou
Jan Henning
Mihai Alexandru Michis
Razvan Maries
Matt Woodrow
Jean-Yves Avenard
Sylvestre Ledru