Open Bug 1336232 Opened 7 years ago Updated 2 years ago

TextArea input in new polymer-based Gerrit (PolyGerrit) is very slow

Categories

(Core :: Layout, defect, P3)

54 Branch
defect

Tracking

()

Tracking Status
firefox54 --- affected

People

(Reporter: TD-Linux, Unassigned)

References

()

Details

Navigate to the URL and log in with any Google account. Click Reply and try typing in the text field. The entry is very slow and tends to accumulate events - the faster you type the more it lags behind. On my profiler, it looks like the time is pretty evenly split 50/50 between style and graphics.

Putting ?polygerrit=0 in the URL is a workaround for those afflicted.
style and graphics sound very much like not DOM ;)
Component: DOM: Core & HTML → Graphics
I don't see much graphics nor css. More layout
Component: Graphics → Layout
Why do we need lots of restyle and frame reconstruction in this case?

It seems that, every time I press a key, some script would do a series of DOM mutation, mostly noticably the a series of changes to style attribute of the reply window, which removes each property one by one, and re-add the same properties one by one again. The changed property includes position, z-index, top, left, box-sizing, max-{height,width}. Some of them can trigger frame reconstruction, and some can trigger reflow. If some code path triggers a flush before all properties are added back, there may be wasted cycles. But I'm not sure whether this is the true reason.

Enabling "Highlight painted area" seems to indicate that there is always a large repaint, which may be caused by the unnecessary frame reconstruction.
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.