GeckoView always calls preserveLayers(true) on all <browser> elements,
which causes the puppet widget to always be considered visible.
Given how the code worked before, aBrowsingContext.isActive = false
after that call would deactivate the pres shell, but after my patch it
stops doing so.
We don't really want to un-throttle the refresh driver etc just because
we're preserving layers, so propagate the state to the child process and
account for that in the logic to determine PresShell activeness.
Depends on D118703
Differential Revision: https://phabricator.services.mozilla.com/D118884
This moves the logic of whether a pres shell should be active to a
single place to make it sane to reason about, and fixes the
subdocument propagation when a BrowserChild becomes visible.
Differential Revision: https://phabricator.services.mozilla.com/D118703
This moves the logic of whether a pres shell should be active to a
single place to make it sane to reason about, and fixes the
subdocument propagation when a BrowserChild becomes visible.
Differential Revision: https://phabricator.services.mozilla.com/D118703
See rationale in bug 1698693 comment 9.
The added flags ensure we stop at the RSF even if it's overflow:hidden,
or if the starting frame is in fixed content.
Depends on D117387
Differential Revision: https://phabricator.services.mozilla.com/D117388
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
