Open
Bug 1509499
Opened 6 years ago
Updated 2 years ago
Typing in a textarea is sluggish when page contains RLM control characters
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Core
Layout: Text and Fonts
Tracking
()
NEW
People
(Reporter: jfkthame, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: perf, testcase)
+++ This bug was initially created as a clone of Bug #1296050 +++ Adding text to a <textarea> element is sluggish when the page contains a [[left-to-right (U+200E) or]] right-to-left (U+200F) mark. There is a noticeable delay after each keystroke. To reproduce this issue, try typing a string of characters into the textarea of each of the pages below: * Page with RLM: https://people.wikimedia.org/~ori/T143182/with-rlm.html * Same page, no RLM: https://people.wikimedia.org/~ori/T143182/no-lrm.html The page with the RLM is much slower. This is affecting certain Wikipedia edit pages. See https://phabricator.wikimedia.org/T143182 for user reports. - - - - - Bug 1296050 added an optimization to avoid this issue where only LRM (not RLM) is present, but the RLM case remains. From bug 1296050 comment 19: >> (2) Try to limit bidi resolution to only the dirty paragraphs. Bidi >> resolution algorithm is paragraph-based, so do it on the whole block isn't >> necessary. > To implement this, I think we can do: > * when nsTextFrame::CharacterDataChanged is called, find the boundary of > paragraph this change touches > * record the boundary somewhere > * only resolve the corresponding paragraphs when there are boundaries recorded > For the specific case of typing, we can probably just do this optimization when > there is only one paragraph involves, which should improve the input > responsibility for majority of the cases.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•