The TextNodeCorrespondenceRecorder stuff doesn't handle display: contents or
Shadow DOM at all. This causes a failure with an upcoming patch.
This patch fixes it and fixes related crashes like bug 1563779. This is the same
wallpaper as bug 1421807.
Differential Revision: https://phabricator.services.mozilla.com/D49138
--HG--
extra : moz-landing-system : lando
This is causing problems since leaving a non-default appearance changes margins
and borders. This was wallpapered by XBL failing to load a binding and leaving
the element without frame as described in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D49061
--HG--
extra : moz-landing-system : lando
For huge sizes we may end up with an unconstrained isize. Just avoid sizing the
window to that.
Differential Revision: https://phabricator.services.mozilla.com/D49062
--HG--
extra : moz-landing-system : lando
We could put this change itself behind a pref too, if we considered that worth
it. But probably not so.
Differential Revision: https://phabricator.services.mozilla.com/D48010
--HG--
extra : moz-landing-system : lando
I use `warningFlag` instead of `infoFlag` because even if the principal
writing-mode propagation is written in the spec, its effect might
surprise the developers.
Differential Revision: https://phabricator.services.mozilla.com/D48774
--HG--
extra : moz-landing-system : lando
Per the css-contain specification, size contained elements must be sized as if
they were empty. Up until now, we've been handling that by just using "0" as
the intrinsic size of some components, but that doesn't actually match the size
of a "true" empty select, which has some nonzero width from:
(a) the default inline-axis padding on the display frame (added in a rule for
the ::-moz-display-comboboxcontrol-frame pseudo, in forms.css).
(b) the width (inline-size) of the display frame's "placeholder" space
character, which has a small intrinsic width (but which really only exists
for *block-axis* sizing and alignment, when no option is selected from
the dropdown).
This patch addresses issue (a) by explicitly adding the display frame's
inline-axis padding to size-contained elements, and it addresses issue (b) by
changing to use a zero-width space character in empty select elements.
So: as of this patch, size-contained select elements are getting a little wider
(to address (a)), and empty select elements are also getting a little skinnier
(to address (b)), and they'll end up being the same width.
(I chose U+FEFF "zero-width non-breaking-space" since we were previously using
a non-breaking space character. I'm not sure if the non-breaking aspect matters,
but I figured I'd preserve that to be on the safe side.)
Differential Revision: https://phabricator.services.mozilla.com/D48791
--HG--
extra : moz-landing-system : lando
I'm not happy about all the SVG text / disallow out of flow complexity sprinkled
during frame construction... :(
Maybe we should add some kind of more generic mechanism to disallow some
children for particular kinds of frames, or something.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D44808
--HG--
extra : moz-landing-system : lando
Without this patch, the `CHECK_BLOCK_AND_LINE_DIR` soft assertion in
nsFloatManager can be triggered with
wm-propagation-body-dynamic-change-002.html added in Part 3.
Add the test as a crashtest because web-platform reftest doesn't seem to
catch our soft assertions.
Add reftests to verify that BFC bits are added to the child block if the
parent and child has the same block-direction, but different sideways
bit; also, add reftests to ensure that "text-orientation: sideways"
doesn't add BFC bits.
Differential Revision: https://phabricator.services.mozilla.com/D45912
--HG--
extra : moz-landing-system : lando
In 817406-4.html, `<body style="direction: rtl;">` needs to propagate up
to `<html>`, so we should compare its result to 817406-1-ref.html.
Differential Revision: https://phabricator.services.mozilla.com/D45482
--HG--
extra : moz-landing-system : lando
Per the css-contain specification, size contained elements must be sized as if
they were empty. Up until now, we've been handling that by just using "0" as
the intrinsic size of some components, but that doesn't actually match the size
of a "true" empty select, which has some nonzero width from:
(a) the default inline-axis padding on the display frame (added in a rule for
the ::-moz-display-comboboxcontrol-frame pseudo, in forms.css).
(b) the width (inline-size) of the display frame's "placeholder" space
character, which has a small intrinsic width (but which really only exists
for *block-axis* sizing and alignment, when no option is selected from
the dropdown).
This patch addresses issue (a) by explicitly adding the display frame's
inline-axis padding to size-contained elements, and it addresses issue (b) by
changing to use a zero-width space character in empty select elements.
So: as of this patch, size-contained select elements are getting a little wider
(to address (a)), and empty select elements are also getting a little skinnier
(to address (b)), and they'll end up being the same width.
(I chose U+FEFF "zero-width non-breaking-space" since we were previously using
a non-breaking space character. I'm not sure if the non-breaking aspect matters,
but I figured I'd preserve that to be on the safe side.)
Differential Revision: https://phabricator.services.mozilla.com/D48791
--HG--
extra : moz-landing-system : lando
... where we've lost track of the display: contents style already since the
ancestor has become display: none, but the first-line belongs to a higher
ancestor that hasn't. Pretty nasty.
Differential Revision: https://phabricator.services.mozilla.com/D48368
--HG--
extra : moz-landing-system : lando
At
https://searchfox.org/mozilla-central/rev/2f29d53865cb895bf16c91336cc575aecd996a17/layout/generic/nsGfxScrollFrame.cpp#3166
we sort the scrollbar parts based on hovered state so that the hovered scrollbar is on top of a non-hovered scrollbar. This means that changing the hover state of a scrollbar can change the ordering of the scrollbar display items in the display list. So when the hover state changes we need to mark the frames modified.
I'm guessing the reason this didn't come up before is because we needed a combination of scrollbars that don't have any style changes on hover and a platform that has hover events. I'm guessing GeckoView scrollbars don't have a style change on hover, and we don't commonly have a mouse or mouse like cursor device hooked up to GeckoView devies to have hover events. Except Firefox Reality has a cursor thingy so we see the problem there.
Differential Revision: https://phabricator.services.mozilla.com/D48234
--HG--
extra : moz-landing-system : lando
At
https://searchfox.org/mozilla-central/rev/2f29d53865cb895bf16c91336cc575aecd996a17/layout/generic/nsGfxScrollFrame.cpp#3166
we sort the scrollbar parts based on hovered state so that the hovered scrollbar is on top of a non-hovered scrollbar. This means that changing the hover state of a scrollbar can change the ordering of the scrollbar display items in the display list. So when the hover state changes we need to mark the frames modified.
I'm guessing the reason this didn't come up before is because we needed a combination of scrollbars that don't have any style changes on hover and a platform that has hover events. I'm guessing GeckoView scrollbars don't have a style change on hover, and we don't commonly have a mouse or mouse like cursor device hooked up to GeckoView devies to have hover events. Except Firefox Reality has a cursor thingy so we see the problem there.
Differential Revision: https://phabricator.services.mozilla.com/D48234
--HG--
extra : moz-landing-system : lando
This can also fix bug 1586470.
This change basically reverts Bug 1025669 Part 1.
https://hg.mozilla.org/mozilla-central/rev/ae2fd5b2defb0df1bd30521f4793de6757d1e98b
In box-decoration-break-block-margin.html, the `height` in `.inner` is
changed to 79px so that 79px plus 7px margin top and 1px margin end,
total 87px, can be divided by 3 (columns). The modification to reference
file reflects what we currently rendered.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D48484
--HG--
extra : moz-landing-system : lando
Without this patch, the `CHECK_BLOCK_AND_LINE_DIR` soft assertion in
nsFloatManager can be triggered with
wm-propagation-body-dynamic-change-002.html added in Part 3.
Add the test as a crashtest because web-platform reftest doesn't seem to
catch our soft assertions.
Add reftests to verify that BFC bits are added to the child block if the
parent and child has the same block-direction, but different sideways
bit; also, add reftests to ensure that "text-orientation: sideways"
doesn't add BFC bits.
Differential Revision: https://phabricator.services.mozilla.com/D45912
--HG--
extra : moz-landing-system : lando
In 817406-4.html, `<body style="direction: rtl;">` needs to propagate up
to `<html>`, so we should compare its result to 817406-1-ref.html.
Differential Revision: https://phabricator.services.mozilla.com/D45482
--HG--
extra : moz-landing-system : lando
We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They
weren't quite good because:
1. While loading an iframe, they were being registered twice with the same
ids(for about:blank and the real URL) sometimes.
2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child
processes if the parent is in a different process. That may not be the case for
now, but it will be after fission.
So we had to find other IDs to:
1. Determine the Tab of the frames.
2. Determine the URLs of the frames.
For the first use case, we were using nsDocShell::mHistoryId for that purpose
but that was wrong. The closest thing that we can get to a tab ID is
BrowsingContext ID because they don't change after a navigation. But iframes
have different BrowsingContext's, so we still need to create a tree to
construct a tab content. That can be either in the front-end or capture time.
For the second use case, we were using a key pair of mHistoryId and mOSHE. We
now chose to keep inner window IDs for that purpose. Inner window IDs are
unique for each navigation loads because inner window correspond to each JS
window global objects. That's why we can use that without any problem. But one
problem is that we cannot handle `history.pushState` and `history.replaceState`
changes with that change since window global objects won't change during those.
But that was the best thing we can do after fission. So this will be a small
sacrifice for us to keep that functionality working after fission.
In that patch we also remove the registration/unregistration calls. We are
going to add those calls in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D47065
--HG--
extra : moz-landing-system : lando
Adds a way for mochitest, reftest, and crashtests to skip XBL related
tests when XBL is disabled. Also, add an app constant so JS can
check whether XBL is enabled.
Depends on D45614
Differential Revision: https://phabricator.services.mozilla.com/D45615
--HG--
extra : moz-landing-system : lando
When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
--HG--
extra : moz-landing-system : lando
The only thing it does is asserting a bit and posting more async work to the
text frame. It seems we can just post all the async work early instead, and
remove the change hint.
This was only introduced to fix bug 779971, where a <textPath> element
references its parent SVG, which is obviously unsound if we allowed to render
it.
What we're doing right now is a bit silly... We're observing the <svg>, so when
we finish reflowing it and store its overflow, we invalidate its rendering
observers, but that invalidates a _descendant_, which makes no sense.
Fortunately we don't let the element affect its rendering, as it fails this
check:
* https://searchfox.org/mozilla-central/rev/35cc00a25c4471993fdaa5761952bd3afd4f1731/layout/svg/SVGObserverUtils.cpp#1390
But we still request reflow of the outer <text>, which is not amazing. We
shouldn't invalidate anything if the textpath doesn't reference a valid element
and that didn't change. This is roughly what the code tried to do when checking
mValid, except we always initialize mValid to true and thus always trigger at
least one bogus reflow call.
Differential Revision: https://phabricator.services.mozilla.com/D48008
--HG--
extra : moz-landing-system : lando
What we actually care about here is whether itemRect is empty bceause that's
the what we'll use for the actual surface size.
Differential Revision: https://phabricator.services.mozilla.com/D48548
--HG--
extra : moz-landing-system : lando
It's always used along with nsChangeHint_RepaintFrame, which does most of the
work.
It's only useful to skip calling SyncFrameViewProperties(). That call is really
cheap if nothing actually changed, furthermore since only a handful of frames
actually have views.
So it doesn't seem like it serves any useful purpose.
Differential Revision: https://phabricator.services.mozilla.com/D48003
--HG--
extra : moz-landing-system : lando
Otherwise we may keep the scroll anchor around and we may try to anchor to it
later even though we should've really suppressed it completely.
Maybe we should just call InvalidateAnchor() unconditionally from that code
path, even if there are no suppressions pending...
Differential Revision: https://phabricator.services.mozilla.com/D48456
--HG--
extra : moz-landing-system : lando
This makes things better especially when the bounds of the combined blob
is changing but the bound of the separate ones are not.
The current implementation is a bit ugly, but it's simple and
can be cleaned up in the cleanups I have in mind for the future.
Differential Revision: https://phabricator.services.mozilla.com/D47983
--HG--
extra : moz-landing-system : lando
