This should pretty much match our non-fission behavior. I found the
original approach of keeping the frameloader from nsSubDocumentFrame
quite hard to get green on try unfortunately, because among other
things, the new frameloader wouldn't get the right viewport sizes /
position / etc.
Differential Revision: https://phabricator.services.mozilla.com/D121198
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
* Per advice from Emilio on Matrix, I consolidated overflow checks into `ScrollFrameHelper::GetOverflowState()`.
* In `ScrollFrameHelper::ReflowFinished` we detect the condition requring the app to expand the toolbar.
(Hiro, I know that you suggested a second place to detect this. If you feel that it is important enough to add that,
we'd prefer filing a follow-up bug in Layout for that case that your team can follow up on.)
* We then propagate the notification through `PresShell`, up through `PBrowser`, through the `nsWindow`, then into the `GeckoSession`
* We invoke a new method on the `ContentDelegate`. This seemed like the reasonable delegate to use given other existing
callbacks in the similar vein (such as going fullscreen), but let me know if this should go elsewhere.
* We update GVE and JUnit tests to test this.
Differential Revision: https://phabricator.services.mozilla.com/D120499
In the most common case the first call to FindViewContaining has aRelativeToView = aView = the root view of the root content document, and we start in visual coords. Then we convert to layout coords and call FindViewContaining recusively with aRelativeToView = the root view again, aView = a child of the root view and working in layout coords. And we still satisfy the conditions to set crossingZoomBoundary to true, which is incorrect because we already crossed. We need to check that we are also in visual coords.
Differential Revision: https://phabricator.services.mozilla.com/D105438
Since bug 1717726 we've disallowed having remote <browser> or remote <iframe>
inside nsDeckFrame which means `captureingFrame` in ClearMouseCapture(nsIFrame*)
function will never be called in an out-of-process thus we can use
IsAncestorFrameCrossDocInProcess there.
Also add an assertions that the function gets called only with a child frame of
nsDeckFrame since this function is used only inside nsDeckFrame.
Depends on D119068
Differential Revision: https://phabricator.services.mozilla.com/D119069
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
