See this profile: https://share.firefox.dev/3sWTcYN

I left the profiler running on Nightly on my Windows laptop. It looks like it painted every 15s in the profiler tab for 900s... and then kept painting, but only in the parent and gpu process.
Looks like the cause is a 15000ms ScrollFrameHelper::ResetDisplayPortExpiryTimer timer.

I haven't tried to reproduce so I don't know if it happens every time or if specific steps to reproduce are needed.

(In reply to Florian Quèze [:florian] from comment #0)

I haven't tried to reproduce so I don't know if it happens every time or if specific steps to reproduce are needed.

I restarted/updated Nightly. It doesn't reproduce if I leave it on the what's new page that opened after the update. But it does reproduce consistently if I leave a profiler tab in the foreground before I stop touching the machine for multiple minutes.

The severity field is not set for this bug.
:hiro, could you have a look please?

For more information, please visit auto_nag documentation.

I encountered this again today: https://share.firefox.dev/3HGBrTI

Timothy, do you know what the expected behavior of this code is? It looks like you reviewed it in bug 990916.

Worked with [:florian] on this a bit today and I think we have a reasonable STR. We were able to reproduce this reliably by:

1. Open the profile here: https://share.firefox.dev/3jzY1FF
2. Start profiling using the power preset
3. Wait for a few minutes
4. Finish the profile
5. In the resulting profile, filter the markers by Reset

With this I can see ScrollFrameHelper::ResetDisplayPortExpiryTimer is clearly running every 15 seconds.

Do not allow the displayport for the first scrollable frame to expire.

Simpler STR

The attached minimal example is a simpler page to reproduce the issue with. Steps to reproduce are:

1. Open displayport-expiry.html.
2. Start a profile (most configurations should work, but I used the Power preset).
3. Click the green div and leave the mouse there for a minute or so
4. Stop the profile and in the marker table for the content thread search for Reset

Discussion

It appears that PaintFrame will always try to activate the first found displayport here. Assuming the first found displayport has a child scrollable element that has been expired, we can get caught in a loop of expiring the first displayport here and activating the first displayport in PaintFrame.

Solution

My current solution in D169861 was to set a flag indicating that the displayport was the first displayport found by PaintFrame, and therefore we shouldn't let the displayport expire. This "works", but I'd certainly appreciate feedback on the approach.

After digging a bit through bugzilla I noticed bug 1714717. I think fixing bug 1714717 would be an alternate method of fixing this bug.

(In reply to Dan Robertson (:dlrobertson) from comment #8)

After digging a bit through bugzilla I noticed bug 1714717. I think fixing bug 1714717 would be an alternate method of fixing this bug.

After some more thought, this wouldn't fix the issue for the fission disabled case, so it's probably not the best route forward to fix this particular issue.

I just saw this again: https://share.firefox.dev/3xKXKmB
This time the profiler wasn't involved. I don't have exact steps to reproduce, all I know is my cat moved around on the keyboard (they are many keyboard events at the beginning of the profile) and then I saw devtools was there.

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