It's not like we're going to change behavior here anytime soon anymore
(other than removing XUL usage), and the helpfulness of the warning has
probably decreased with time.
But maybe I'm missing a reason why it should be kept around?
Differential Revision: https://phabricator.services.mozilla.com/D73544
For whatever reasons, we pass body element into
`RecreateFramesForContent`, the root element won't be reframed down in
the `ContentRemoved` path, but in `ContentRangeInserted()` path while
checking `WipeContainingBlock`. And in bug 1593752, we already have the
logic to reframe root element only when html and body's writing-modes
are different, so we won't over-eagerly reframe the root element.
Differential Revision: https://phabricator.services.mozilla.com/D71606
According to spec, option elements with label attributes should show and use
those labels rather than their element text. So let's do that.
Requires some trickery because the option element is a block element (so it
lays out its width based on its text content) so we put its label (if it has
one) in its ::before and skip frame generation so it measures the text of its
label, not of its text node children.
Differential Revision: https://phabricator.services.mozilla.com/D63545
According to spec, option elements with label attributes should show and use
those labels rather than their element text. So let's do that.
Requires some trickery because the option element is a block element (so it
lays out its width based on its text content) so we put its label (if it has
one) in its ::before and skip frame generation so it measures the text of its
label, not of its text node children.
Differential Revision: https://phabricator.services.mozilla.com/D63545
Both PresShell() and PresContext() are cached in nsIFrame. This
simplifies the setup for the callers to
nsCSSFrameConstructor::CreateContinuingFrame().
Differential Revision: https://phabricator.services.mozilla.com/D66600
The nsPresContext* argument of
nsCSSFrameConstructor::CreateContinuingFrame() is used only to get
PresShell. However, mPresShell is already cached in
nsCSSFrameConstructor (via its base class nsFrameManager).
By switching to use the cached value, we can remove now-unused
nsPresContext* or PresShell* from some continuing-frame-creation
methods' argument list in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D66599
`nsFrameConstructorState::ProcessFrameInsertions` has a 600+ byte stack frame due to its `AutoTArray`s. If this function becomes indirectly inlined into the recursive parts of `nsCSSFrameConstructor`, that will bloat the callers' stack frames and make us pay 600 bytes at every level of recursion. Crashtests aren't happy about that on stack-limited Win32 builds.
This inlining has not yet happened in official builds, but did occur in my try runs for bug 1619461 where the inliner became more aggressive.
Differential Revision: https://phabricator.services.mozilla.com/D65815
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
