Both for symmetry with other string APIs, and also to prevent footguns (since I
debugged for a while a typo where I wrote nsGkAtoms::empty rather than
nsGkAtoms::_empty).
We could use null here, but that will not be possible in the future when I use
the rust representation of more grid data structures (at least without
increasing memory usage).
So I think I'll keep using ::_empty as a signaling value for "no grid
identifier".
Differential Revision: https://phabricator.services.mozilla.com/D35120
--HG--
extra : moz-landing-system : lando
The style system already atomizes all CustomIdent values, which means that we're
just wasting memory and CPU by doing string copies all over the place.
This patch fixes it. This also simplifies further changes to use as much of the
rust data structures as possible.
I had to switch from nsTHashtable to mozilla::HashTable because the former
doesn't handle well non-default-constructible structs (like NamedLine, which
now has a StyleAtom, which is not default-constructible).
Differential Revision: https://phabricator.services.mozilla.com/D35119
--HG--
extra : moz-landing-system : lando
Right now we do a lot of useless string copying. In order to avoid transcoding
to utf-16 during layout, make sure to use nsCString at a few related places.
I may revisit this since we're storing other line names as atoms in some places.
So it may be better to just use atoms everywhere.
But that'd be a different patch either way.
Depends on D35116
Differential Revision: https://phabricator.services.mozilla.com/D35117
--HG--
extra : moz-landing-system : lando
There's two things going on here. 1) nsGfxScrollFrame is getting the
wrong renderroot, because it's not correctly recursing up the frame
tree. 2) Hiding behind that problem is that if we do correctly assign
the renderroot, we end up blocking on both render roots updating if
we don't, say, have a horizontal scroll option, because that leaves
us with a wr::RenderRoot::Default. 2.1) We then still end up blocking
on the default renderroot because we initialize the selector with
WebRenderBridgeParent's mRenderRoot.
Differential Revision: https://phabricator.services.mozilla.com/D31858
--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
This change doesn't affect behavior, but is probably needed to build
successfully in a non-unified-build configuration.
--HG--
extra : amend_source : 6617eaa171d1b1e294d2f3657d1d94688758b3e6
The regressor Bug 1248708 inadvertently changed the behavior for opacity 0 text
when implementing -webkit-text-stroke. It treats all opacity 0 text as drawing stroke
even if the stroke property isn't used in the first place.
We should check aParams.textStrokeWidth is actually set before changing draw mode.
Differential Revision: https://phabricator.services.mozilla.com/D34663
--HG--
extra : moz-landing-system : lando
This is consistent with the scroll area events too, and allows us to
remove the WillPaintObserver stuff.
Differential Revision: https://phabricator.services.mozilla.com/D5271
--HG--
extra : moz-landing-system : lando
The root displayport has some assumptions built into it about being positioned at
the origin and sized to the composition bounds that seem like they only apply to
the cross process root content document. This commit changes us to avoid taking
this code path for OOP-iframes.
Differential Revision: https://phabricator.services.mozilla.com/D34527
--HG--
extra : rebase_source : 026bb84b7ad086f508228620d19d9f459f28bf1d
Otherwise clamped positions in layer pixels might cause 1-pixel difference
in CSS pixels on Android.
Note that there is a fundamental issue on the interaction between
the layer-pixel alignment and scrolling APIs (bug 1556685), once we fix the bug
properly, we should use the scrolled position, which was given by the scrolling
APIs, for the current position.
Differential Revision: https://phabricator.services.mozilla.com/D32779
--HG--
extra : moz-landing-system : lando
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
nsDisplayRemote no longer has any direct ties to RenderFrame and should
be moved to nsSubDocumentFrame.cpp where it's actually used/created.
Differential Revision: https://phabricator.services.mozilla.com/D33563
--HG--
extra : rebase_source : ae2e03108820bd14b5f2771da17cabfd95706f94
extra : source : b301161ab461cd46cea3f91749896686c50e9b9f
extra : histedit_source : 1c80f83d26734e56bd6353f0a50dcbc4bf894b4b
Code outside of BrowserParent should just get the LayersId from a getter
and not worry about RenderFrame.
Differential Revision: https://phabricator.services.mozilla.com/D33562
--HG--
extra : rebase_source : 63f9f9680a7cb16a18d9e56999e02a124aa63429
extra : source : e86839ca63260b09184755c98890fa8abf371530
extra : histedit_source : 34333f5f78ecf9b4f3e12c6175a6e81724a41fb2