when downloading large files from solidworks.com, firefox becomes unresponsive due to SMIL animations in hidden (display none) subtrees
Categories
(Core :: SVG, defect)
Tracking
()
People
(Reporter: chaplain, Unassigned)
References
Details
Attachments
(5 files)
download.JPG
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Steps to reproduce:
1 - I go to https://www.solidworks.com/support/free-downloads and download a large file. I suggest "SOLIDWORKS PCB Viewer" since it is 1/2 GB and requires so subsequent verification.
2 - Execute any activity that requires additional file downloads. Examples include an un-cached page in another tab or other file downloads from this or other web pages.
OR try to run the FF performance profiler while the download is in process.
Actual results:
Initial file download comes to a near complete halt. FF taking 75% of quad core Intel CPU clicks. Roughly 37% in FF and 37% in Windows system (as observed with Process Explorer which lags for all FF related process queries as well). In most cases, FF does not recover - even if download and page loads are canceled. Only reliable recovery is to restart FF.
Issue seems to be particular to downloads on the page in question. I've downloaded a number of files from other servers without issue.
NOTE: this unresponsiveness is specific to processes requiring new data requests - for un-cached http page info or other file downloads. Switching tabs, entering text in forms, scrolling page displays proceeds normally without excessive lag.
Expected results:
File should download in background while FF operates normally.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
Hi,
I am not able to replicate the issue. I've tried on windows 10 pro, on latest release, beta and nightly builds.
Can you follow the steps at https://firefox-source-docs.mozilla.org/performance/reporting_a_performance_problem.html and share a performance profile recording of this issue? and then upload the profile using 'upload local profile' button?
I've assigned a component in order to get the dev team involved.
Thanks for the report.
Best regards, Clara.
|
|
||
Comment 3•3 years ago
|
||
I've used the same file as you did.
The download finished without issues and ff didn't become unresponsive.
(In reply to Clara Guerrero from comment #2)
Created attachment 9247999 [details]
Firefox 2021-10-27 11.19 profile.json.gzHi,
I am not able to replicate the issue. I've tried on windows 10 pro, on latest release, beta and nightly builds.
Can you follow the steps at https://firefox-source-docs.mozilla.org/performance/reporting_a_performance_problem.html and share a performance profile recording of this issue? and then upload the profile using 'upload local profile' button?I've assigned a component in order to get the dev team involved.
Thanks for the report.
Best regards, Clara.
Thanks Clara. As I noted above, I tried to run the profiler while the issue was occurring and it only provided another way to lock up FF.
Having said that I am sitting in front of a different computer running the same FF profile and I can't reproduce the problem here. I'm going to need to try this again in front of the offending installation.
I'll keep you posted.
Clara,
I have returned to the machine where I had the issue. I am still having it but not as severely as before. I've captured a profile. My method was start 3 identical downloads and surf a bit. The profile link is https://share.firefox.dev/3jKDxqg
Neil
|
|
||
Comment 6•3 years ago
|
||
The severity field is not set for this bug.
:Gijs, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 7•3 years ago
|
||
(In reply to Neil from comment #5)
Clara,
I have returned to the machine where I had the issue. I am still having it but not as severely as before. I've captured a profile. My method was start 3 identical downloads and surf a bit. The profile link is https://share.firefox.dev/3jKDxqg
Neil
My read of this profile (after zooming back out to https://share.firefox.dev/3FiMXC2 ) is that there's some extension that's causing 10s of seconds of jank (freezing) in the parent process (main Firefox UI) which is causing the problem here. Florian, can you check that I'm looking at the right thing? The extension URLs have been removed from the profile so it's impossible to tell which one (and strangely, though our webextension framework code appears in the stack, it would appear the code of the extension involved does not, unclear to me if that's the profiler filtering it out or something else).
|
|
||
Updated•3 years ago
|
|
||
Comment 8•3 years ago
|
||
(In reply to :Gijs (he/him) from comment #7)
(In reply to Neil from comment #5)
Clara,
I have returned to the machine where I had the issue. I am still having it but not as severely as before. I've captured a profile. My method was start 3 identical downloads and surf a bit. The profile link is https://share.firefox.dev/3jKDxqg
NeilMy read of this profile (after zooming back out to https://share.firefox.dev/3FiMXC2 ) is that there's some extension that's causing 10s of seconds of jank (freezing) in the parent process (main Firefox UI) which is causing the problem here. Florian, can you check that I'm looking at the right thing?
The big jank marker in the parent process has a duration of >90h, it's most likely bogus. Looking at the marker chart in the profile, there are dom events being processed and we paint things, so I don't think the parent process was actually janky.
The profile was captured without the stackwalk feature, so we have very little information about what the native code was doing.
The extension URLs have been removed from the profile so it's impossible to tell which one (and strangely, though our webextension framework code appears in the stack, it would appear the code of the extension involved does not, unclear to me if that's the profiler filtering it out or something else).
There's some function names of extensions visible in the WebExtensions track.
There's a lot of activity in the profile, it's hard to know what was intended (due to downloading many files and having many add-ons installed) and what might be issues worth investigating.
|
|
||
Comment 9•3 years ago
|
||
The severity field is not set for this bug.
:Gijs, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Comment 10•3 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #8)
The profile was captured without the stackwalk feature, so we have very little information about what the native code was doing.
<snip>
There's a lot of activity in the profile, it's hard to know what was intended (due to downloading many files and having many add-ons installed) and what might be issues worth investigating.
Can you suggest alternative instructions that would provide an actionable profile here?
|
|
||
Comment 11•3 years ago
|
||
(In reply to :Gijs (he/him) from comment #10)
(In reply to Florian Quèze [:florian] from comment #8)
The profile was captured without the stackwalk feature, so we have very little information about what the native code was doing.
<snip>
There's a lot of activity in the profile, it's hard to know what was intended (due to downloading many files and having many add-ons installed) and what might be issues worth investigating.Can you suggest alternative instructions that would provide an actionable profile here?
- Using the "Firefox platform" profiler preset instead of the "Web Developer" one (this can be set from the profiler popup menu before starting the profiler) would give us native stacks.
- Reproducing the bug in a separate Firefox profile where there's no sensitive user information, so that the profile could be shared with URLs and Extension information at the time of upload would also be nice. Or if there was no intent to remove this information from the profile in the first place, then uploading the profile with the various checkboxes checked in the upload panel to include all the information would be nice.
|
|
||
Comment 12•3 years ago
|
||
From looking again at the profile from comment 5, it looks like the "Download Manager (S3)" add-on (https://addons.mozilla.org/en-US/firefox/addon/s3download-statusbar/) is playing a big role in all the activity that's happening, so it would be interesting to know if the problem can still be reproduced after disabling this add-on.
|
|
||
Comment 13•3 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #11)
(In reply to :Gijs (he/him) from comment #10)
(In reply to Florian Quèze [:florian] from comment #8)
The profile was captured without the stackwalk feature, so we have very little information about what the native code was doing.
<snip>
There's a lot of activity in the profile, it's hard to know what was intended (due to downloading many files and having many add-ons installed) and what might be issues worth investigating.Can you suggest alternative instructions that would provide an actionable profile here?
- Using the "Firefox platform" profiler preset instead of the "Web Developer" one (this can be set from the profiler popup menu before starting the profiler) would give us native stacks.
- Reproducing the bug in a separate Firefox profile where there's no sensitive user information, so that the profile could be shared with URLs and Extension information at the time of upload would also be nice. Or if there was no intent to remove this information from the profile in the first place, then uploading the profile with the various checkboxes checked in the upload panel to include all the information would be nice.
(In reply to Florian Quèze [:florian] from comment #12)
From looking again at the profile from comment 5, it looks like the "Download Manager (S3)" add-on (https://addons.mozilla.org/en-US/firefox/addon/s3download-statusbar/) is playing a big role in all the activity that's happening, so it would be interesting to know if the problem can still be reproduced after disabling this add-on.
Neil, would you be able to follow Florian's suggestions and get back to us with more info? Thanks.
|
Reporter | |
Comment 14•3 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #12)
From looking again at the profile from comment 5, it looks like the "Download Manager (S3)" add-on (https://addons.mozilla.org/en-US/firefox/addon/s3download-statusbar/) is playing a big role in all the activity that's happening, so it would be interesting to know if the problem can still be reproduced after disabling this add-on.
Florian/Gjis - My apologies for the tardy reply. Per Florian's suggestions, I created a new profile, installed the S3 download-statusbar and enabled the profiler. I captured the simultaneous download for 4 copies of the same file from https://www.solidworks.com/support/free-downloads with 6 or 7 other tabs open. The profiler data is at https://share.firefox.dev/3EavfQT I told it to include all of the data options in the upload. Hope this helps. I will run a second one with S3 uninstalled and pass it along next.
Side note: this is my second attempt at this. The first time I tried I got a little carried away in the download file count (8 or 9 files and 3x the bytes). That one caused the profiler to use all my available memory and send windows into "file swap hell." Had to power cycle the machine and start over. Don't know whether having two profiles open during that first attempt (and the other profile had MANY unrelated tabs open) might have been an issue - although I would hope not! This attempt I only had the target profile open.
|
|
Reporter | |
Comment 15•3 years ago
|
||
Here is the second try with S3 disabled. I didn't see any real difference. I continued using the same instance of the application. I disabled S3, started the profiler and downloaded 4 duplicates of the same file I downloaded before. The profiler link is: https://share.firefox.dev/3pdeM8h
|
|
||
Comment 16•3 years ago
|
||
In the profile from comment 15 I noticed we have 60Hz RefreshDriverTick markers with "Tick reasons: HasObservers (SMIL animations [Style])".
After looking at the source code of the https://www.solidworks.com/support/free-downloads page, I noticed it has an svg animation inside a display:none div. I made a reduced testcase, and that's enough to reproduce.
Here is a profile of the testcase I'm attaching: https://share.firefox.dev/31lnWHE
Emilio, is this expected? Can we do something to disable vsync for SMIL animations that are hidden? (feel free to forward the needinfo to whoever would know this area)
|
||
Comment 17•3 years ago
|
||
SMIL seems driven by the DOM. It should be possible to not animate on display:none subtrees, though I'm not sure there's any spec requirement for that? Brian, Daniel, do you see anything fundamentally wrong with stopping SMIL sampling when the target elements are not rendered?
|
||
Comment 18•3 years ago
•
|
||
I think it would matter if you have:
<rect ... >
<animate attributeName="display" values="inline, none, inline" dur="3s" />
</rect>
I'm pretty sure that previously worked.
|
|
||
Comment 19•3 years ago
|
||
Updating the summary now that we've identified a cause, and moving this over to layout as a better approximate location; please feel free to move further if that's not quite right either.
|
||
Comment 20•3 years ago
|
||
Here's a testcase along the lines of Brian's comment 18, which does indeed work right now (but would presumably stop working by hiding the square forever, if we didn't sample SMIL animations in display:none subtrees).
|
|
||
Comment 21•3 years ago
|
||
Here's another breaktest where display:none is the initial styling, specified in the inline style attribute, which becomes overridden at 1s with a SMIL animation.
|
|
||
Comment 22•3 years ago
•
|
||
We could potentially stop sampling in display:none subtrees except for [or unless-there-are] animations that affect the display property, though. That should help here without affecting the breaktests.
|
|
||
Updated•3 years ago
|
|
||
Comment 23•3 years ago
|
||
Take care also if you've a use element that points to something that's display:none.
|
|
||
Comment 24•2 years ago
|
||
The severity field is not set for this bug.
:TYLin, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 25•2 years ago
|
||
I'll give this bug S3 for now. Daniel or Robert, feel free to bump the severity.
|
|
Reporter | |
Comment 26•2 years ago
|
||
I've just seen similar behavior to my original report when downloading clonezilla (https://clonezilla.org/downloads/download.php?branch=stable). The download transfers to osdn.net and Firefox (now 91.5.0esr x64) hardly functions until download is complete.
|
|
||
Comment 27•2 years ago
|
||
(In reply to Neil from comment #26)
I've just seen similar behavior to my original report when downloading clonezilla (https://clonezilla.org/downloads/download.php?branch=stable). The download transfers to osdn.net and Firefox (now 91.5.0esr x64) hardly functions until download is complete.
It would be nice if you could capture a profile of this. The bug when downloading on this other website might be very different from the bug we already identified here.
|
|
Reporter | |
Comment 28•2 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #27)
(In reply to Neil from comment #26)
I've just seen similar behavior to my original report when downloading clonezilla (https://clonezilla.org/downloads/download.php?branch=stable). The download transfers to osdn.net and Firefox (now 91.5.0esr x64) hardly functions until download is complete.
It would be nice if you could capture a profile of this. The bug when downloading on this other website might be very different from the bug we already identified here.
Florian, I've done as you asked. I have created a new profile - so my add-on were not running. I down loaded 3 files and visited some other pages. I will note that an empty profile performs better but still shows excessive CPU clicks.
I will also note that on my first attempt I performed the same actions but when I went to capture the profile Firefox showed the "Importing profile directly from Firefox" window for over 20 minutes before I killed it and tried again. So this profile link is my second attempt. . .
Description
•