1731009 - With fission enabled, the demo on https://codepen.io/amit_sheen/pen/PojjzjB stutters (throttles?) unless you continuously move the mouse inside the demo pane

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Mayank Bansal]

1. Enable Fission (either via the fission.autostart pref, or via Nightly experiments)
2. Go to https://codepen.io/amit_sheen/pen/PojjzjB

AR: The demo is stuttery. Now start moving the mouse inside the demo pane. The demo will become very smooth.

Note that while the demo is stuttering, the CPU use is not high, which would imply some sort of throttling?

This is not a recent regression. A build from Jun-2020 also shows this behaviour.

Comment 1

[Mayank Bansal]

If you export the demo to your local machine and run the demo from there, there is no stuttering.
Edit: I dont know if this is a known bug or not. In any case, feel free to WONTFIX or Dupe

Comment 2

[Mayank Bansal]

Attachment: about:support with fission enabled

Comment 3

[Chris Peterson [:cpeterson]]

The animation is janky for me with or without Fission. The animation oscillates between smooth and janky every few seconds. I can't tell whether enabling Fission or moving the mouse makes any difference. I recorded two performance profiles:

Profile with Fission disabled:
https://share.firefox.dev/2XqpLRD

Profile with Fission enabled:
https://share.firefox.dev/2VLcIJR

For some reason the profile with Fission disabled doesn't include the GPU process, even though I see a GPU process listed in about:processes.

Comment 4

[Mayank Bansal]

Here is a profile with Fission enabled : https://share.firefox.dev/3hE7dEy

In this, i kept the mouse stationary for the first 5 seconds, and then started moving it inside the animation/demo pane after the 5 second mark
Edit: The above profile is from a different demo by the same author : https://codepen.io/amit_sheen/pen/mdwqXEv

Comment 5

[Chris Peterson [:cpeterson]]

(In reply to Mayank Bansal from comment #4)

Edit: The above profile is from a different demo by the same author : https://codepen.io/amit_sheen/pen/mdwqXEv

Thanks for the second test case. I can reproduce the problem very clearly with that "Daily Planet" test case:

• With Fission disabled, the animation is always smooth.
• With Fission enabled, the animation is choppy when the mouse pointer is not moving and smooth when I move the mouse pointer rapid over the animation.

Here are my profiles of the Daily Planet demo. In each profile, I kept my mouse still for the first five seconds and then moved the mouse pointer rapidly over the animation for the next five seconds.

Profile with Fission disabled:
https://share.firefox.dev/2XlkJWp

Profile with Fission enabled:
https://share.firefox.dev/2XA2Gw8

Comment 6

[Chris Peterson [:cpeterson]]

This is not a recent regression because I can also reproduce this bug in Firefox 92 and Beta 93.

Comment 7

[Darkspirit]

Gnome Xwayland, Debian Testing, Intel
MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 2019-06-25 --bad 2020-03-01 --pref gfx.webrender.all:true fission.autostart:true -a https://codepen.io/amit_sheen/pen/PojjzjB

6:34.42 INFO: Last good revision: 26711f10f5f45471b5856fb5cef08948f0e5bc21 (2019-09-11)
6:34.42 INFO: First bad revision: f60e7f5f8557d4f385cb182a995fb537f2cb7611 (2019-09-12)
6:34.42 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=26711f10f5f45471b5856fb5cef08948f0e5bc21&tochange=f60e7f5f8557d4f385cb182a995fb537f2cb7611

Comment 8

[Markus Stange [:mstange]]

In that range, it could be bug 1541705, bug 1580063 or bug 1574493.

Hiro, can you take a look? The refresh ticks on the main thread are skipped because we think the compositor is running the animation, but the compositor isn't advancing the animation (or WR somehow ignores the animations effects), it seems.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

Yeah, bug 1541705 is the culprit. In the test case in comment 0, this aFrame->GetRelativeToSelf() returns an empty rect, that's the cause.

Comment 10

[Chris Peterson [:cpeterson]]

This is a bad bug. Tracking for Fission MVP.

Comment 11

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1731009 - Properly check whether the given nsIFrame is inside an OOP Iframe visible rect or not even if the frame size is (0x0). r?tnikkel,boris

Before this change, in nsLayoutUtils::FrameIsScrolledOutOfViewInCrossProcess
we call BaseRect::IsEmpty() for the returned value of GetFrameVisibleRectOnScreen,
unfortunately if the returned value size is (0x0), BaseRect::IsEmpty() returns
true thus we misthink the given nsIFrame is out of the visible area of the OOP
iframe where the nsIFrame lives.

Note that we have already done the same check for in-process cases in
IsFrameScrolledOutOfView [1].

The test case in this change fails without this change, suceeds with
the change. Though, to be honest, I don't know the reason those styles
, display: grid, etc. generate (0x0) sized frame even if decendants have
sized.

[1] https://searchfox.org/mozilla-central/rev/15de05f0e6d841cbc2ac66f8dcad72ebdada47f6/layout/generic/nsIFrame.cpp#11090-11094

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4256690c306d
Properly check whether the given nsIFrame is inside an OOP Iframe visible rect or not even if the frame size is (0x0). r=tnikkel

Comment 13

[Andreea Pavel [:apavel]]

Backed out for build bustages

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=4256690c306d341507d07924520a8228da370ea8&selectedTaskRun=KiIGp9ndQTCxnD6KYgnA8Q.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=352361789&repo=autoland&lineNumber=49265

Backout: https://hg.mozilla.org/integration/autoland/rev/dc6105abe71019a22f2b0a35662c150312444d36

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ae9abfaa385d
Properly check whether the given nsIFrame is inside an OOP Iframe visible rect or not even if the frame size is (0x0). r=tnikkel

Comment 15

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/ae9abfaa385d

Comment 16

[Mayank Bansal]

This is fixed. Thanks!

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:hiro, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 18

[Chris Peterson [:cpeterson]]

:hiro, is this bug important enough to require an uplift?

If this bug only affects Fission users, then we don't need to uplift to Beta 93. We don't plan to run any Fission experiments in Release 93, so no users would be affected.

Comment 19

[Hiroyuki Ikezoe (:hiro)]

Thank you Chris for the current Fission plan. The patch only affects OOP iframe cases.

Comment 20

[Cristian Fogel [:cfogel]]

Confirmed issue with 94.0a1 Build ID 20210915152638.
Verified patch with 94.0b2

Comment 21

[Mihai Boldan, Desktop QA [:mboldan]]

Based on Comment 20, I'm marking this issue as Verified Fixed.