Open
Bug 1344377
Opened 7 years ago
Updated 2 years ago
Jank with unnecessary frame reconstruction & layout, when tweaking "position" on root of deeply-nested frame tree
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
Details
(Keywords: perf)
Attachments
(2 files, 1 obsolete file)
STR: 1. Load attached testcase. 2. Click "FIRST" (and then wait a few seconds for page to update) 2. Click "SECOND" (and then wait for alert to appear) ACTUAL RESULTS: Alert reports times of 4+ seconds (4000ms). EXPECTED RESULTS: Shorter times. e.g. chrome gives 9ms NOTES w.r.t. other bugs: - I'm spinning this off of bug 1342220 (the testcase is roughly based on the Twitter scenario in that bug) - This might be the same as bug 1261484, under the hood. We can dupe later, as-needed, but for now I'm filing this separately, because bug 1261484 is theoretical whereas here we've got an actual testcase with measurable performance.
Reporter | ||
Comment 1•7 years ago
|
||
Comment hidden (obsolete) |
Reporter | ||
Comment 3•7 years ago
|
||
Attachment #8843485 -
Attachment is obsolete: true
Reporter | ||
Comment 4•7 years ago
|
||
Average on Windows with "testcase 2 (simpler)", attachment 8843488 [details] (rough average after performing a few measurements):
Measurement Browser Version
=========== ================
2000ms Firefox Nightly 54 (2017-03-03)
300ms Edge 14
3ms Chrome 58
Comment 5•7 years ago
|
||
CC'ing myself and Surkov, too, since this also shows our accessibility performance problem. In testcase 1, before the Alert appears after those about 2800 milliseconds, there are 20 or so seconds when accessibility is on that aren't measured with this, but which clearly come from us recreating the whole accessible stuff. And that's with E10S off, which in accessibility land is more performant still. Alex, please take a look at these and use them to measure where we spend all that time.
(In reply to Daniel Holbert [:dholbert] from comment #0) > - This might be the same as bug 1261484, under the hood. We can dupe > later, as-needed, but for now I'm filing this separately, because bug > 1261484 is theoretical whereas here we've got an actual testcase with > measurable performance. Also see bug 1261484 comment 7, which might deserve being split off as a separate bug.
Updated•7 years ago
|
Whiteboard: [qf:p1]
Updated•7 years ago
|
Assignee: nobody → bugs
Updated•7 years ago
|
Assignee: bugs → dholbert
Reporter | ||
Comment 7•7 years ago
|
||
This was [qf:p1] in the interests of improving a really bad case on twitter (Bug 1342220), but I'm going to try to address Bug 1342220 by suggesting that Twitter change their CSS, as noted in Bug 1342220 comment 21. So this bug can now be [qf:p3] -- known perf issue & opportunity for optimization, but not known to impact websites (beyond twitter which we'll hopefully be addressing with outreach such that this won't be an issue for them).
Assignee: dholbert → nobody
Whiteboard: [qf:p1] → [qf:p3]
Updated•7 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Performance Impact: --- → P3
Whiteboard: [qf:p3]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•