1615131 - Like `nsRange`, `StaticRange` instances should also be reused as far as possible

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, task)

Description

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

When we start to dispatch beforeinput event with supporting InputEvent.getTargetRanges(), editor needs to compute the ranges and then, need to create StaticRanges to represent the target ranges. However, it may cause performance regression due to:

1. computation cost of target ranges.
2. allocation cost of StaticRange instances.
3. initializing cost of StaticRange instances including computing startOffset and endOffset for fixing them.
4. allocation cost of array of RefPtr<StaticRange>.

In these necessary cost, we can avoid the 2nd cost with same approach as bug 1612085.

Comment 1

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

Attachment: Bug 1615131 - Make `StaticRange` instances reused as far as possible like `nsRange` r=smaug!

When we support InputEvent.getTargetRanges(), editor needs to create
StaticRange instances at starting to handle every edit operations/commands.
Therefore, we need a hack for saving allocation cost like nsRange.

This patch moves nsRange::MaybeCacheToReuse() and nsRange::Shutdown() to
AbstractRange to reduce copy&paste same code into nsRange and StaticRange.
However, Create(nsINode*) and Release() are duplicated unfortunately.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/937ce62849e0
Make `StaticRange` instances reused as far as possible like `nsRange` r=smaug

Comment 3

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/937ce62849e0