Jank with unnecessary frame reconstruction & layout, when tweaking "position" on root of deeply-nested frame tree

NEW
Unassigned

Status

()

P3
normal
2 years ago
11 months ago

People

(Reporter: dholbert, Unassigned)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(firefox54 affected)

Details

(Whiteboard: [qf:p3])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

2 years ago
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)

Updated

2 years ago
See Also: → bug 1261484
(Reporter)

Comment 1

2 years ago
Created attachment 8843475 [details]
testcase 1
Comment hidden (obsolete)
(Reporter)

Comment 3

2 years ago
Created attachment 8843488 [details]
testcase 2 (simpler)
Attachment #8843485 - Attachment is obsolete: true
(Reporter)

Comment 4

2 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
(Reporter)

Updated

2 years ago
See Also: → bug 1344398
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.
Whiteboard: [qf:p1]

Updated

2 years ago
Assignee: nobody → bugs
Assignee: bugs → dholbert
(Reporter)

Comment 7

2 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]
(Reporter)

Updated

a year ago
No longer blocks: 1342220
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.