We need to move EditorEventListener::HandleMiddleClickPaste() into
EventStateManager to handle middle click paste after all click events are
dispatched. This is preparation of the change.
HandleMiddleClickPaste() uses UIEvent::GetRangeParent() and
UIEvent::RangeOffset() to collapse Selection at clicked point. However,
EventStateManager cannot access them since EventStateManager can handle it
with WidgetMouseEvent. Fortunately, only WidgetMouseEvent is necessary for
implementing them. Therefore, we can move the implementation into
nsLayoutUtils and merge them.
Differential Revision: https://phabricator.services.mozilla.com/D7851
--HG--
extra : moz-landing-system : lando
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9
Specifically:
- nsICSSAnonBoxPseudo --> nsCSSAnonBoxPseudoStaticAtom
- nsICSSPseudoElement --> nsCSSPseudoElementStaticAtom
The `nsI` prefix isn't necessary because these are no longer XPIDL types, and
the `StaticAtom` suffix makes their meaning clearer.
--HG--
extra : rebase_source : b68dd7c73f5036dcd6be4c3700b757441f59f9f2
Previously we would log the displayport and the critical displayport separately,
which made it more difficult to write cross-platform APZ tests.
Differential Revision: https://phabricator.services.mozilla.com/D7341
--HG--
extra : rebase_source : ef2d87b7f9314bb5e6943a8da2b4fd40de85c99b
extra : histedit_source : 80f1e914330f1be0a7a5e531356e6b869b0d29ac
When one of the two factors governing the effective container width for font
inflation changes, we need to mark all affected frames as dirty.
While the visible area commonly changes because of viewport changes and we can
catch those through the check for ISize resizes of the top-level frame
("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation
of the effective container width into the FontInflationData itself, especially
since the effective container width calculation in nsLayoutUtils is the only
consumer of the NCAISize currently stored by the FontInflationData.
That way
- we can be sure that really all changes of the visible width will correctly
mark all affected frames as dirty
- can avoid repeatedly recalculating the effective container width
- can also detect the cases where the effective container width actually remains
the same after a change in one of its input factors and skip forcing a full
dirty reflow for all descendants just because of font inflation.
While the code in nsLayoutUtils was technically always using the writing
mode (horizontal/vertical) of each individual frame for determining which
dimension of the visible size should be used for clamping, just using the
writing mode of the respective flow root should be enough, since each change in
the writing mode should create a new flow root.
This assumption should already hold today because
1. as per the Writing Modes CSS spec, a change in writing mode compared to its
parent means that the affected block cannot be purely "inline", but at most
"inline-block".
2. Generally, any non-inline frame will be marked as a font inflation container.
3. Any block frame whose writing direction doesn't match its parent will be a
block formatting context, which implies NS_BLOCK_FLOAT_MGR.
4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation
container will also become a font inflation flow root.
but because this chain of reasoning is not the most direct, we also add a
corresponding assertion to better catch any potential bugs here.
Differential Revision: https://phabricator.services.mozilla.com/D5578
--HG--
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
Markers are taking so much time(~10%) to allocate and in a website
like Speedometer, it takes ages to load the profile data since
there are so many frame construction markers.
Differential Revision: https://phabricator.services.mozilla.com/D7064
--HG--
extra : moz-landing-system : lando
This patch make nsCSSFrameConstructor::CreateGeneratedContentItem() early
returns if the originating element contains an UA Widget shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D6828
--HG--
extra : moz-landing-system : lando
We rely on the bit being on the block to restyle them in the right order.
Differential Revision: https://phabricator.services.mozilla.com/D7086
--HG--
extra : moz-landing-system : lando
We're trying to insert a table caption via an append into a display: contents
element. We pass the content-insertion-frame (the table frame) instead of the
siblings' parent (the table wrapper frame).
This is the right thing to pass though, we adjust the caption parent frame
later, on AdjustCaptionParentFrame, and we ensure that we don't get here for a
non-caption thing because of IsValidSibling (though note that that can actually
lie, see bug 1424656, we'd get the layout wrong if the title element was a
replaced element for example), so a normal append without a previous sibling
will still be correct.
It'd be nice to make this a bit less messy, fwiw, but I don't have the ideas or
the time to do it now.
Differential Revision: https://phabricator.services.mozilla.com/D7067
--HG--
extra : moz-landing-system : lando
nsCSSFrameConstructor::FindDisplayData() guarantees a block with "display:
list-item" will be constructed by ConstructBlock() (either through
ConstructScrollableBlock() or ConstructNonScrollableBlock()).
This is also a preparation to fix bug 1491915 since we want to control
bullet frame creation under column hierarchy.
Depends on D6840
Differential Revision: https://phabricator.services.mozilla.com/D6841
--HG--
extra : moz-landing-system : lando
See the discussion in https://github.com/servo/webrender/issues/1280. I think we
should do this sooner rather than later.
Need to update a couple reftests to hardcode the new colors, waiting on try for
that but should be trivial.
This makes a few more tests pass which are just marked as failure in bug 1487407,
because I implementing the border-collapsing reusing a bunch of Gecko code,
including the table 3d border stuff.
Differential Revision: https://phabricator.services.mozilla.com/D6565
Ryan VanderMeulen
Masayuki Nakano
Gurzau Raul
Cameron McCormack
Manuel Rego Casasnovas
Emilio Cobos Álvarez
Narcis Beleuzu
Daniel Varga
Brindusan Cristian
Edgar Chen
Andrea Marchesini
Brad Werth
Botond Ballo ext:(%2C%20Brad%20Werth%20%3Cbwerth%40mozilla.com%3E)
Nicholas Nethercote
Jan Henning
Andrew McCreight
Jonathan Watt
Jeff Muizelaar
Ehsan Akhgari
Noemi Erli
Nazım Can Altınova
Timothy Guan-tin Chien
Coroiu Cristina
Jonathan Kew
Ting-Yu Lin
Neil Deakin
Andreea Pavel