I favor two-argument SetComputedLogicalMargin() for clarity in this
patch series because it works for any pair of writing mode and logical
margin.
Spoiler alert: the one-argument SetComputedLogicalMargin() will be
removed in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D95366
This adds NS_FRAME_FIRST_REFLOW to the frame state flags
we're NOT updating overflow for. This is a minor performance
optimization.
Differential Revision: https://phabricator.services.mozilla.com/D94395
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
We treat it exactly the same as -moz-broken. The pseudo-class is not
exposed to content, so I don't think we have a reason to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D89904
Instead add a pseudo-class that does the expected size="" attribute parsing.
Removing the Gtk-specific rule setting the text color since it doesn't
seem to have any effect currently.
Differential Revision: https://phabricator.services.mozilla.com/D83448
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
In favor of the NativeAnonymous versions which they forward to.
Done automatically with:
rg -l 'IsInAnonymousSubtree' | xargs sed -i 's/IsInAnonymousSubtree/IsInNativeAnonymousSubtree/g'
And removing the function definitions afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D76681
This patch is generated by using my editor's rename functionality.
In the next patch, `nsIFrame::` prefix is going to be removed manually
from all the ChildLists() calls.
Differential Revision: https://phabricator.services.mozilla.com/D75893
The right place to set the bit was in
nsIFrame::SetMayHaveTransformAnimations() (i.e. when we call
KeyframeEffect::UpdateEffectSet) for cases where we add transform animations.
on an nsIFrame which has been already initialized.
Depends on D75050
Differential Revision: https://phabricator.services.mozilla.com/D75051
The pref flip in this bug causes an assertion to fail in
layout/generic/crashtests/1137723-1.html.
Our behavior in that crashtest is so messed up that I can't even begin
to describe it.
That test-case has three-pages, and a link inside a fixed-pos subtree,
which has a ::after pseudo-element.
Via the magic of nsCSSFrameConstructor::ReplicateFixedFrames, we end up
constructing multiple frames, one per page, for the fixed subtree.
We end up with a link with three different ::after pseudo-elements (one
on each page), of which the link only knows about the latest one.
This means that when restyling the link (which was already broken, it
just didn't happen before the prefs), we'd visit the pseudo-element in
some other place of the frame tree we can get a hand on.
Restyling these frames is generally not supported and will do ~nothing,
given the current setup. There's no way to get a hand from the DOM node
to all its replicated frames.
But that's not something I plan to fix for this bug, and this assertion
is blocking me.
Differential Revision: https://phabricator.services.mozilla.com/D72755
The only user is nsFileControlFrame, which can just use the attribute change
callback instead to sync the disabled attribute value with the button.
Syncing tabindex in that attribute callback was wrong since bug 505355.
Differential Revision: https://phabricator.services.mozilla.com/D68740
To get the logical content size of a frame, some callers use
GetContentRectRelativeToSelf().Size() and then convert it to
LogicalRect. We really should generalize ContentBSize(), and provide
ContentSize() for such purpose.
Differential Revision: https://phabricator.services.mozilla.com/D68065
This is probably an old-ish bug made more frequent by the font loading
optimizations.
PostRebuildAllStyleData is a bit of a misnomer, but was always calling
ClearCachedData() on the style set, even if we weren't guaranteed to restyle
every element.
This means both wasted work and correctness issues (as the "uses <rare-feature>"
bits are cleared during this call, on the assumption that we'll then visit all
elements and that'd recompute it properly).
For now, unify a bit the different code paths and only clear these bits if we're
guaranteed to restyle all elements.
I should rename this to something better in a follow-up, and ideally also
decouple the ClearCachedData() calls a bit...
Differential Revision: https://phabricator.services.mozilla.com/D65740
There were some callers in nsRangeFrame that were already not-null-checking.
All platforms have a native theme and should we add new ones they could use
nsBasicNativeTheme.
Differential Revision: https://phabricator.services.mozilla.com/D65169
When our position changes from / to absolute / fixed, then we need to reframe
(most likely, at least). But in some easier cases we can just live with a reflow
plus (optionally) a containing-block update or a repaint, depending on the case.
We need to delete the normal position property when this happens and we switch
from static to relative/sticky, and also need to update the handling of
UpdateContainingBlock to avoid making decisions based on position not changing.
This will actually not cause more reframes, as one would expect, because that
optimization became somewhat obsolete by bug 1519371 (which made the
optimization exact).
Differential Revision: https://phabricator.services.mozilla.com/D61142
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
This attribute is not expected to change often, so it seems fine to restyle the
whole subtree.
Bug 1598094 tracks further optimizations, should they be needed.
Differential Revision: https://phabricator.services.mozilla.com/D54034
So we do it while we're still handling re-entrant changes for SVG, since SVG can
post change hints from UpdateOverflow().
Differential Revision: https://phabricator.services.mozilla.com/D12102
:ntim was about to add another widget-affecting property (pointer-events) to
menupopups to replace the mousethrough attribute, see bug 1597120.
But pointer-events is inherited, and thus changing pointer-events on any element
would cause a change list of length == the number of descendants of the element,
which is not amazing.
So I suggested using DidSetComputedStyle instead, as this is fairly
popup-specific, but we may as well be consistent and do the same everywhere.
This removes the code to handle the -moz-window-* properties on the root frame,
as I haven't seen any usage of them (we always set them in panel or menupopup).
Differential Revision: https://phabricator.services.mozilla.com/D53377
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
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
