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)

defect

Tracking

()

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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.