During double tap animations we can be in a situation where we get two repaint requests from every layers update. The first one comes from NotifyLayersUpdated and scroll offset update type is eNone, the second from the zoom animation ticking has scroll offset update type eUserAction and there was a layout scroll position update. Both can have some amount of aync zoom (not necessarily equal), and have the same content pres shell resolution.
We handle the eNone one first, and update the content pres shell resolution. Then for the eUserAction we check the content presshell resolution and it no longer matches, so we drop the request entirely thinking its out of date (including the scroll position update). It's not out of date of course, content hasn't done any updates, so apz has the latest info (even if it might not have a fully up to date value of the content pres shell resolution, it's value of zoom is the most up to date of anywhere).
Differential Revision: https://phabricator.services.mozilla.com/D114587
So that margin is not included in the rect for visibility calculations,
and padding and margin are accounted properly on them.
Differential Revision: https://phabricator.services.mozilla.com/D113853
Surprisingly nothing actually schedules a paint when the resolution changes.
This probably wasn't a problem because when the resolution changes almost certainly something else is changing that causes a paint too (scroll position, display port, etc).
We hit this in the test I wrote for bug 1706868. We double tap zoom in. In the last RequestContentRepaint from apz to content the only thing that changes is the resolution by a small amount. If he scroll offset or display port margins changed we'd ask for a paint, but evidently they do not. Content updates it's resolution, but since it does not generate a paint apz never gets notified about this, so it thinks content has a slightly different resolution.
Then the test starts a double tap zoom out. When it notifies content of the new resolutions APZCCallbackHelper does nothing because of this line
https://searchfox.org/mozilla-central/rev/4648b6ee31c2519b1753023e4f4853b14fdd16e5/gfx/layers/apz/util/APZCCallbackHelper.cpp#335
where it detects that the content resolution and what apz thinks is the content resolution differ by too much, so it thinks the request from apz is out of date and ignores it.
Differential Revision: https://phabricator.services.mozilla.com/D113614
By resolving the relevant promises, instead of crashing (and if we
didn't crash we'd leave the window registered as a refresh driver
observer, which would be bad).
I wanted to reject them, since that's what we do when the page has no
pres shell, but that'd make this test fail:
https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/base/test/browser_promiseDocumentFlushed.js#165-186
For this, we modify the OneShotPostRefreshObserver API to be more
generic (and rename it OneShotManagedRefreshObserver).
We fix APZ's usage of this API, which was doing something extremely
weird (returning a refcounted object in a UniquePtr). This seems like an
artifact from recent OneShotPostRefreshObserver cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D111851
PresShell::SetIsActive(/* aIsActive */ true) does not directly trigger rendering. On Android, there is a case that rendering of about:support is not updated when PresShell::SetIsActive(true) call is slow during Tab switch.
Differential Revision: https://phabricator.services.mozilla.com/D110682
Actually the page in this case starts getting styled _after_ the load
event, sometimes, but when that happens that also causes a white flash
in other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D109392
Actually the page in this case starts getting styled _after_ the load
event, sometimes, but when that happens that also causes a white flash
in other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D109392
These APIs are entirely unused (aside from one usage in a test, which part 1 in
this patch series removed), so this patch shouldn't impact behavior at all.
Historical note: we briefly removed these APIs once before, in this commit:
https://hg.mozilla.org/mozilla-central/rev/c216ff19d690
...but we brought them back because we had a motivating use case at the time.
We don't have any such motivating use cases any more, though. So, this patch
here is essentially a modernized version of that older commit.
Differential Revision: https://phabricator.services.mozilla.com/D108148
Even with the above fixes, this is not enough to fix all the
invalidation issues, because frame update notifications arrive for the
proxies of the inner image, not for the frozen image.
The simpler thing to do here is sync-decoding for print preview like we
do for print documents.
I think imgRequestProxyStatic is the only thing that can suffer from
these issues (because other ImageOps users like image-orientation don't
create a fake proxy).
Depends on D108198
Differential Revision: https://phabricator.services.mozilla.com/D108199
UnionRectEdges() and UnionEdges() are equivalent, and the later has a
modern interface with a shorter name. Let's remove the former.
Differential Revision: https://phabricator.services.mozilla.com/D107315
I'm not sure whether we should deal with ancestor scales and such. There
seemed to be a discussion about that in D77436 but dealing with
partially-3d-transformed content sounds like a massive pain. For now
this fixes the start point, which is a progression.
Differential Revision: https://phabricator.services.mozilla.com/D106896
I assume nsIFrame::IsAbsolutelyPositioned()'s callers really want to
check whether a frame is a real abspos frame, not just check a frame has
a abspos style. This could potentially change the behavior, but I feel
its the right thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D106580
Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
Kartikaya Gupta
Timothy Nikkel
Emilio Cobos Álvarez
Edgar Chen
sotaro
Mark Striemer
Butkovits Atila
Bogdan Tara
Cosmin Sabou
Miko Mynttinen
Simon Giesecke
Csoregi Natalia
Noemi Erli
Florian Quèze
Olli Pettay
Steven MacLeod
Daniel Holbert
Ting-Yu Lin
Kagami Sascha Rosylight
Mihai Alexandru Michis
Hiroyuki Ikezoe