1627341 - Major performance degradation for invisible elements

Status: RESOLVED DUPLICATE of bug 1730284

(Core :: Layout, defect, P3)

Description

[yotamhod2]

Attachment: Execution times for JS code within the frame before, and after toggling off visibility: hidden !important

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

Steps to reproduce:

My React web application necessitates an iframe which runs an intensive background process. Given that the actual HTML contents of the iframe are of no visual importance to the user, I make the element invisible with the following CSS styling: visibility: hidden !important;

Actual results:

In Chrome, all is well, and the process completes in around 2 seconds.
In Firefox however, the process takes around 2 minutes.

Expected results:

Interestingly, when I toggle off or remove the 'visibility' styling from the iframe, the process speeds up at once, and completes within seconds. I expect JS performance in hidden iframes to be the same as non hidden ones.

Comment 1

[Sean Feng [:sefeng211]]

Hey yotamhod2, thanks for reporting it.

Do you think you can provide a small html test case that can reproduce this problem? Or can you please capture a profile for this slow processing by using https://profiler.firefox.com/?

Comment 2

[yotamhod2]

(In reply to Sean Feng [:sefeng] from comment #1)

Hey yotamhod2, thanks for reporting it.

Do you think you can provide a small html test case that can reproduce this problem? Or can you please capture a profile for this slow processing by using https://profiler.firefox.com/?

The link below should demonstrate my use case when toggling on 'visibility: hidden;'. Unfortunately I have been unsuccessful in my attempts to run this test on firefox due to CSP violations which prevent me from importing the libraries which I use in my case. Perhaps you know of a way to run this jsfiddle in firefox... (It runs on Chrome).

https://jsfiddle.net/m8c02phv/6/
See console.log for times

Anyhow I am now under the impression that the slow down occurs more specifically to asynchronous code in an iframe that is embedded in another iframe.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Attachment: invisible.html

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

I've tried to get the testcase working, but I'm not really sure what it should do.
When one downloads invisible.html and run it from a local, it does do something (without CSP issues), but whether that is the right thing, not sure.
Reporter, could you perhaps help a bit here.
And should the test be run with visibility: hidden? that seems to cause some error in rendition.js

Comment 5

[yotamhod2]

(In reply to Olli Pettay [:smaug] from comment #4)

I've tried to get the testcase working, but I'm not really sure what it should do.
When one downloads invisible.html and run it from a local, it does do something (without CSP issues), but whether that is the right thing, not sure.
Reporter, could you perhaps help a bit here.
And should the test be run with visibility: hidden? that seems to cause some error in rendition.js

Thank you for attaching the file.
This example demonstrates rendering a book in an iframe embedded within another iframe, as this was my original use case when I encountered the issue.
A script running on an interval constantly turns the page, and when a page turn is complete (page turn is asynchronous) the time is logged to console.
When visibilty is hidden in Firefox, notice how the console.logs demonstrate a significant slowdown (filter out the warnings and errors to see only logs).
For some reason the demonstration is resource intensive and is throwing a lot of warnings. Not sure why, my original use case runs cleanly and thus the issue was very noticeable. If necessary I will attempt to create a clearer demonstration when I find time, although your file does seem to demonstrate the issue.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

but with that testcase I'm seeing similar numbers in Firefox (Nightly) and Chrome.

What should be hidden and how, to show the issue? That is the part I don't yet know.

Comment 7

[yotamhod2]

(In reply to Olli Pettay [:smaug] from comment #6)

but with that testcase I'm seeing similar numbers in Firefox (Nightly) and Chrome.

What should be hidden and how, to show the issue? That is the part I don't yet know.

The external most iFrame, with id "myFrame", should be hidden to demonstrate the slowdown. You can use the firefox inspector, click 'myFrame', and check the 'visibility: hidden' box. You should see the console.logs stop/slow down. (You may have to do it quickly in this example, because it seems to stall after some time).

Comment 8

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 9

[Denis Palmeiro [:denispal]]

The Performance Priority Calculator has determined this bug's performance priority to be P3.

Platforms: Windows
[x] Affects animation smoothness

Moving to layout for further investigation.