I thought this would fix <input type=number style="user-select: none">, but
turns out it doesn't.
<input type=number> doesn't have the editor root as a root of the anonymous
subtree, so the current hack wouldn't work, as the anon root wouldn't have the
editable flag. So tweak the code a bit to handle stuff in a simpler way than
setting the flags after the fact, and set the NAC-root flag earlier to avoid
the mOuterWrapper->AppendChildTo(root) call forgetting about root's flags.
I had to tweak one AccessibleCaret test, but that's because it uses <textarea>
with user-select: none, and our behavior there is not particularly sane. It just
happened to work because that test-case also had a bunch of contenteditable
elements, and we stop matching this rule:
https://searchfox.org/mozilla-central/rev/220a3bd6063fcbe5ca50e88dcabdc7dee0aca448/layout/style/contenteditable.css#22
Because the anonymous div now properly matches :-moz-read-write, which made the
rule apply and the test work. See comment 4 of this bug.
I'll fix this stuff up and add some tests for our behavior here in bug 1611699.
I refactored the dragdrop tests to cover more input types, but I ended up not
being able to use them because they're dependent on the content.
Instead I added an extra test and changed the refactor so that it applies to
<input type=search>, as there's layout work going on in bug 558594, and it'd be
unfortunate to regress this there too.
Differential Revision: https://phabricator.services.mozilla.com/D61094
There is no way this ever properly worked, as we always passed null for
`aFrameState`.
So it'd only work if we reframed the document element or such... Which is not
amazing.
For simpler test-cases, when we don't construct the scrollframe via
PresShell::Initialize, but via the regular frame constructor updates
(ContentAppended, etc...), those end up working because we go through lazy frame
construction, which ends up in RecreateFramesForContent, which passes
mTempFrameTreeState.
Differential Revision: https://phabricator.services.mozilla.com/D59569
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
This cleans up and also allows us to keep the distinction between content: none
and content: normal, which allows us to fix the computed style we return from
getComputedStyle().
Do this last bit from the resolved value instead of StyleAdjuster, because
otherwise we need to tweak every initial struct for ::before / ::after.
Differential Revision: https://phabricator.services.mozilla.com/D58276
For BeginBuildingColumns, returning nsBlockFrame, i.e. the original
NS_NewColumnSetWrapperFrame's return type, should be sufficient since no
other caller in frame constructor needs to call ColumnSetWrapper's
methods.
Differential Revision: https://phabricator.services.mozilla.com/D58398
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
This matches the new servo layout engine too, and thus removes some #[cfg]
gunk. Just use `flow` since it doesn't simplify the layout code as much.
Differential Revision: https://phabricator.services.mozilla.com/D45973
When browser.xhtml switches to an <html> root element, the frame structure
changed and caused performance regressions on talos for tart and tresize.
browser.xhtml doesn't need scrolling, so we can disable it and keep performance
on par with XUL <window>.
Differential Revision: https://phabricator.services.mozilla.com/D50675
When browser.xhtml switches to an <html> root element, the frame structure
changed and caused performance regressions on talos for tart and tresize.
browser.xhtml doesn't need scrolling, so we can disable it and keep performance
on par with XUL <window>.
Differential Revision: https://phabricator.services.mozilla.com/D50675
The only caller SetRootElementFrameAndConstructCanvasAnonContent()
already passes nsContainerFrame* to aFrame.
A minor cleanup discovered while working on this bug.
Differential Revision: https://phabricator.services.mozilla.com/D48943
Like visibility, we rely on pointer-events values inheriting down into
scrollbar part elements. So don't cached NAC styles for scrollbar parts
if we have a non-initial value for pointer-events, and adjust the UA
style sheet rules to ensure it is always inherited.
Differential Revision: https://phabricator.services.mozilla.com/D49359
Bug 1102175 Part 1 only handles HTML documents correctly because they
always have a body element (even if the <body> tag is not written
explicitly in the document). For SVG documents and all other documents
lacking <body> element, we always want to propagate mWritingMode from
the root element, which is our old behavior prior to Bug 1102175.
Note that mDocElementContainingBlock (i.e. nsCanvasFrame) is using
viewport's style, so we need to use the root element's computed style to
compute WritingMode for propagating.
Differential Revision: https://phabricator.services.mozilla.com/D49695
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
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
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
