Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
--HG--
extra : moz-landing-system : lando
At first glance, it might look like this would change behavior, since
FinishReflowChild passes aReflowInput to DidReflow, which in turn
notifies aReflowInput's mPercentBSizeObserver. However, if you examine
how the mPercentBSizeObserver is propagated, it can only be set for the
anonymous block wrapping the children of table cells, the children of
table cells, or additionally a child of a table wrapper frame that has
it set (i.e., a table or its caption, when logically a child of a table
cell). Since all of the frames for which this is being changed are
either internal table elements that are inside of the table, or are
things that can never be a descendant of a table at all, there should be
no change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D40565
--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
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
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
For now, always pass null, except when passing it through from one
overload to another.
Differential Revision: https://phabricator.services.mozilla.com/D38389
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
This makes us pass web platform test contain-layout-baseline-004.html (i.e. it
makes us treat that test's 'contain:layout' table-cell as having no baseline,
so we align its bottom edge with the other cell's actual baseline, as the test
expects).
This is required by the spec text at [1] which excludes most table parts but
includes table cells, and says "the containing element is treated as having no
baseline".
[1] https://drafts.csswg.org/css-contain/#containment-layout
Differential Revision: https://phabricator.services.mozilla.com/D37118
--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
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--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
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
--HG--
extra : moz-landing-system : lando
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
