1555919 - (centralize-editor-selection-updates) Make editor not update Selection directly

Status: NEW

(Core :: DOM: Editor, enhancement, P2)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

When I get involved performance issues related to editor, we always see Selection::Collapse() cost and Selection::Extend() cost. When we modify Selection, it needs to invalidate related frames and its cost is really expensive. Additionally, editor may update Selection twice or more while handling an edit action. So, we now pay a lot of unnecessary cost.

So, I think that we should make stop modifying Selection from editor until dispatching input event. However, this is a special case. If the document has one or more mutation event listeners, we need to update Selection before changing the DOM tree for backward compatibility. I.e., in such web apps, we cannot improve the performance, but it's not major cases since according to the telemetry, most users don't load such web apps.

Perhaps, we should do:

• make each editor method which targets current selection change to take target range(s)
• store "pending" selection range into AutoEditActionDataSetter
• flush it when the DOM tree is changed in documents having mutation event listeners or dispatching "input" event

Comment 1

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

Discussed via E-Mail: when fixing this issue, let's aim to remove SelectionRefPtr() and pass the Selection (or ranges, I guess) as a parameter so that MOZ_KnownLive usages for SelectionRefPtr()->SomeMethodAnnotatedWithMOZ_CAN_RUN_SCRIPT can be avoided.