Keep a separate list of animations in the timeline that are hidden by
content visibility. This allows the DocumentTimeline to disconnect from
the refresh driver when all animations are hidden and prevents ticking
hidden animations in general.
Differential Revision: https://phabricator.services.mozilla.com/D150764
This patch doesn't change behavior.
Before this patch, the FindBackground API returns a bool to indicate
success/failure, and sets its outparam to a non-null pointer-value on success.
This patch simplifies the API by just promoting the promoting the outparam to
be the actual return value, with nullptr as a sentinel value to indicate
failure.
(This patch adds some braces to affected/contextual if statements, too, to
match our coding style guide.)
Differential Revision: https://phabricator.services.mozilla.com/D149337
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Also bug 1216483
The problem was that GetNextPrevLineFromeBlockFrame correctly identified the target frame but in case it was a flex/grid container, PeekOffsetForLine didn't accept it as a valid result due to a missing line iterator.
There was an existing case which handled this similarly for a table target, drilling into a first child with line iterator, but it was also incomplete.
Extended the drill condition for flex/grid and made the drilling algorithm more robust to be able to also crawl siblings and skip non-selectable elements (e.g. :before pseudoelement, contenteditable="false")
Differential Revision: https://phabricator.services.mozilla.com/D147752
After bug 1730284 we don't use it for throttling iframes, so the only
remaining use the test-only nsIDOMWindowUtils.paintCount. None of the
tests using it rely on the empty transaction case, so we should be able
to just remove this.
Differential Revision: https://phabricator.services.mozilla.com/D146589
After bug 1730284 we don't use it for throttling iframes, so the only
remaining use the test-only nsIDOMWindowUtils.paintCount. None of the
tests using it rely on the empty transaction case, so we should be able
to just remove this.
Differential Revision: https://phabricator.services.mozilla.com/D146589
This is more likely to be understandable by developers, matches other
browsers more closely (see bug comments), and seems more in-line with
what we do for OOP iframes.
Add a pref to not do this throttling at all (which would match Chrome),
though this is probably good enough for now.
Differential Revision: https://phabricator.services.mozilla.com/D146574
visibility: hidden still goes into BuildDisplayListForChild (because
children might be visible), but the child itself might not be visible.
Differential Revision: https://phabricator.services.mozilla.com/D122117
Change to derive from nsDisplayEffectsBase, since the backdrop-filter
can still have a visual bounds (and effect) even if the child
stacking context has no items. Also use the same approach to get
the bounding rect and implement GetBounds as nsDisplayFilters uses.
Differential Revision: https://phabricator.services.mozilla.com/D145295
It's not possible to implement backdrop-filter with gecko adding
explicit boundaries for backdrop roots, since backdrop filters
can sample from a backdrop in a parent iframe. In this case, the
parent display list (in one process) doesn't see a backdrop filter,
so no root display item is added, even if there is a child display
list (in another process) that has a backdrop-filter.
This patch just removes the existing backdrop-filter root display
items from Gecko. A follow up patch will add implicit backdrop
root handling inside WR itself, where we have access to all of the
display lists.
Differential Revision: https://phabricator.services.mozilla.com/D146148
Teach nsDisplay{Filters,BackdropFilters} to use a style that doesn't
belong to mFrame for the root frame, and use it as needed.
Remove the BackdropFilters::CanCreateWebrenderCommands call because it
was testing for StyleSVGEffects::mFilters rather than mBackdropFilters,
so it was doing nothing.
Differential Revision: https://phabricator.services.mozilla.com/D146188
Change to derive from nsDisplayEffectsBase, since the backdrop-filter
can still have a visual bounds (and effect) even if the child
stacking context has no items. Also use the same approach to get
the bounding rect and implement GetBounds as nsDisplayFilters uses.
Differential Revision: https://phabricator.services.mozilla.com/D145295
This has a TODO about empty page names on previous sibling frames, to match
Chrome's behavior of page break coalescing we should be looking to the frame
before that sibling and check for page breaks there instead.
Differential Revision: https://phabricator.services.mozilla.com/D140423
Basically, the transferred min & max sizes shouldn't override the min &
max sizing properties, so applying it earlier than these properties
should be identical. This just makes the flex base size and main size be
more correct at the beginning (and so other adjustments of sizes
in flex algorithm can override the transferred min/max sizes), for
non-replaced elements.
Note:
In Chromium code, it clamps the flex items' base size by transferred min &
max sizes, but the computation of items' used min & used max sizes doesn't
include the transferred min & max sizes.
So in this patch, I'm trying to make this patch simple: we let minimum &
maximum sizes only taken into account for flex base size and only for
non-replaced elements for now. So the behavior should be similar to other
browsers.
And we may have to update this tentative solution once these spec words get
updated.
Differential Revision: https://phabricator.services.mozilla.com/D144499
This is mostly edge-casey, but see bug 1757156 for an example where it's
causing some issues (granted, they could use `href="#"` or something
instead of an empty href).
It feels weird if a link looks like a link (because the CSS definition
of a link matches, which is "has an href") but then mostly doesn't
behave as a link.
We can't navigate anywhere if we don't have a valid URI but maybe JS
handles the relevant events as in bug 1757156.
Use the CSS definition (has href) since that's interoperable across
browsers. This should also make some stuff much faster (since checking
'is link' is now just a bit check instead of a virtual call).
(Awaiting try results, if no tests need adjustments then I need to write
some)
Differential Revision: https://phabricator.services.mozilla.com/D142107
