Interacting with specific element of the PDSP Ki database search form freezes Firefox
Categories
(Firefox :: Untriaged, defect)
Tracking
()
People
(Reporter: aerkiaga3, Assigned: emilio)
References
(Blocks 1 open bug)
Details
(Keywords: perf)
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0
Steps to reproduce:
- Go to https://pdsp.unc.edu/databases/pdsp.php
- Check 'Test Ligand'
- Click the dropdown button at the right of that field
Actual results:
Firefox freezes after a few seconds, the 'MainThread' process at a constant 1 full core CPU usage.
Expected results:
After a quite noticeable but short time interval, a very long dropdown list should have appeared, listing all test ligands for which data exists in the database.
The User Agent listed above corresponds to the browser version and operating system this bug was successfully reproduced on.
Comment 2•5 years ago
|
||
Confirmed with Nightly 83 on Linux.
Comment 3•5 years ago
|
||
https://share.firefox.dev/2S7iYGi hopefully shows the problem.
Emilio, want to have a look? This is spinning in https://searchfox.org/mozilla-central/source/toolkit/actors/SelectChild.jsm#379.
Comment 4•5 years ago
|
||
(In reply to Paul Adenot (:padenot) from comment #3)
https://share.firefox.dev/2S7iYGi hopefully shows the problem.
Emilio, want to have a look? This is spinning in https://searchfox.org/mozilla-central/source/toolkit/actors/SelectChild.jsm#379.
Thanks for the profile! I think the issue is rather in the parent process: https://share.firefox.dev/3n3ZIbh
Assignee | ||
Comment 6•5 years ago
|
||
Assignee | ||
Comment 7•5 years ago
|
||
Same idea, when only one node is slotted or unslotted, we only need to
do work for the rest of assigned nodes iff the slot has dir=auto or a
dir=auto ancestor, and the result of computing the dir=auto ancestor
changes.
Otherwise we just need to propagate the directionality from the slot.
Depends on D91753
Assignee | ||
Comment 8•5 years ago
|
||
Well looking a bit closer, the improvements in the child process are probably a bit minor (micro-optimizing font-family serialization and so on), so probably worth doing in a separate bug.
![]() |
||
Comment 10•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/62a557bcdc10
https://hg.mozilla.org/mozilla-central/rev/d062c1f7777b
Updated•5 years ago
|
Comment 11•5 years ago
|
||
It would be nice to see a profile of the same thing with a build including the patches that have landed.
Comment 12•5 years ago
|
||
Here is a profile after the patch, it's significantly improved but it is still slow for me https://share.firefox.dev/3l6zJ0P
Comment 13•5 years ago
|
||
(In reply to Pascal Chevrel:pascalc from comment #12)
Here is a profile after the patch, it's significantly improved but it is still slow for me https://share.firefox.dev/3l6zJ0P
Thanks Pascal!
Emilio, is there anything in this profile that's actionable and would be worth a follow-up bug?
Assignee | ||
Comment 14•5 years ago
|
||
Yes, I think there are multiple things that could be improved:
- Half of the parent process time is running JS (custom element constructors, etc) which probably could do less work.
- Almost other half (60% of the remaining layout time) comes from
nsTextBoxFrame::DoXULLayout
... Chances are than moving this to something that isn't XUL would massively speed it up, it's not like there's so much text there...
So yeah, let's file a follow-up bug IMO.
Updated•5 years ago
|
Description
•