Rss.beauty is unresponsive in Nightly and continuously uses RAM (3.5GB+) . Works great in Chrome.
Categories
(Core :: JavaScript Engine, task)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
(Depends on 1 open bug, )
Details
Attachments
(3 files, 1 obsolete file)
jandem pointed that this website was on HN and was performing poorly on Firefox.
In Firefox, the page is basically unresponsive, and continuously uses more and more RAM.
Chrome: https://share.firefox.dev/41QpJ4C
Nightly: https://share.firefox.dev/41WnyMR / https://share.firefox.dev/4gXOOid
Nightly with memory tracking: https://share.firefox.dev/4a11PFy
This may be a poorly designed site.
Attaching the about:memory report too in text format.
|
||
Comment 1•1 year ago
•
|
||
The website has a canvas element and it assigns to its .style.all property (it copies all property values and re-assigns them later) and that affects the value of .offsetWidth in Firefox. This results in the buggy and slow behavior.
For the attached test case I get this in Nightly:
width: 300, offsetWidth: 1712
width: 300, offsetWidth: 300
And this in Chrome:
width: 300, offsetWidth: 1712
width: 300, offsetWidth: 1712
I verified that changing the property-assign-loop in a local copy of the website's JS code to ignore the "all" property fixes the slowness.
Safari matches Nightly on this test. I think it avoids the buggy behavior on the original website for a different reason but I haven't looked into this more.
Emilio, any thoughts on this?
|
|
||
Comment 2•1 year ago
|
||
|
||
Comment 3•1 year ago
|
||
Will dig tomorrow, but at a glance it seems like a chrome bug. style.all = "" is basically removeProperty("all") which per spec removes all properties.
This is a similar test-case with another shorthand:
<!doctype html>
<div id="target" style="border-top-color: red"></div>
<script>
target.style.border = "";
</script>
In both Chrome and Firefox, the style attribute is empty after the assignment.
|
|
||
Comment 4•1 year ago
|
||
This site seems to be open-source, do you happen to know where is this loop is?
|
|
||
Comment 5•1 year ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)
This site seems to be open-source, do you happen to know where is this loop is?
That code is part of a library. Searching for a function name I found this code that looks similar. On line 413 it creates the _originalStyle object that's later passed to that function.
|
|
||
Comment 6•1 year ago
|
||
This is a standalone copy of the website. Can be served with python3 -m http.server.
I also beautified some JS files. function gi in script2.js is where it calls setProperty for the CSS properties.
|
|
||
Comment 7•1 year ago
|
||
https://github.com/tsparticles/tsparticles/issues/5443 / https://issues.chromium.org/issues/387030982
I think this bug is invalid. rss.beauty could work around this by not using inline styles on the canvas.
|
|
||
Updated•1 year ago
|
|
|
||
Comment 8•1 year ago
|
||
Thanks for filing these follow-up bugs! Let's close this one.
|
|
||
Comment 10•1 year ago
•
|
||
The style.all fix landed in Chrome Canary but they're still not affected the same way.
It's still fast in Chrome because the CSS2Properties object has the property names sorted, so that all is set before width = 100% whereas in Firefox we have a more arbitrary order and set width = 100% before all.
With a local build if I change the propsData assignment in GenerateCSSPropListWebIDL.py like this we're also fast:
propsData = dict(sorted(runpy.run_path(dataFile)["data"].items()))
I think the better fix may be to sort the JSAPI spec arrays we generate in Codegen.py so that we have a more deterministic property iteration order. I'll file a bug for that.
Description
•