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)
Tracking
()
NEW
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.
Comment 1•7 years ago
|
||
style and graphics sound very much like not DOM ;)
Component: DOM: Core & HTML → Graphics
Comment 3•7 years ago
|
||
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.
Updated•7 years ago
|
Priority: -- → P3
Updated•6 years ago
|
Blocks: QF-Polymer
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•