What's the status of this bug? Perhaps, I can fix bug 998941 soon. Then, I'll work on implementing beforeinput behind a flag. (Perhaps, I need to rewrite a lot especially around keypress event dispatcher, so, still not so urgent though.)

This patch is based on the patch created by Makoto Kato-san.

Range and StaticRange have common base interface, AbstractRange.
https://dom.spec.whatwg.org/#abstractrange

This interface has simply returns startContainer, endContainer,
startOffset, endOffset and collapsed.

Different from the original patch's approach, this patch moves related
members in nsRange to AbstractRange since this approach avoids
virtual call cost. Additionally, this patch makes them not throw as
declared by the spec. As far as I know, the destruction cost of
ErrorResult may appear in profile so that we should avoid creating
the instance if we can avoid it.

Unfortunately, the instance size of nsRange becomes larger with this
patch. The size is changed from 176 to 184. I.e., now, nsRange
requires bigger chunk.

For avoiding confusion between API of nsRange and StaticRange, I'd like to
rename nsRange::CreateRange() to nsRange::MaybeCreate() because
StaticRange::CreateStaticRange() is too long name and
StaticRange::CreateRange() sounds odd. And sometimes, it won't return new
instance. This patch renames it and changes related methods to template
methods for avoiding runtime cost of temporary RawRangeBoundary
instance creation.

Some nsRange static methods are useful in StaticRange and some of them
are used in a lot of places but not related to nsRange directly. This
patch moves them into new static method only class, mozilla::RangeUtils.

This patch is based on Makoto Kato-san's patch.

This patch implements mozilla::dom::StaticRange class and creating some
static factory methods.

Then, makes AbstractRange has a utility method of SetStartAndEnd()
method of nsRange and StaticRange for sharing same logic in one place.
However, there are some additional work is required only in nsRange, e.g.,
nsRange needs to start observing mutation of the range, but StaticRange
does not it. Therefore, it's implemented as a template method which takes
nsRange* or StaticRange* as a parameter. Then, each DoSetRange()
method of them can do different things without virtual calls.

Note that StaticRange does not have any properties, methods nor constructor.
Therefore, we need additional API to test it.

This patch makes HTMLEditRules::ExpandSelectionForDeletion() use StaticRange
instead of nsRange for comparing a point and a range (i.e., the DOM tree
won't be changed during it's alive). Unfortunately, we still have allocation
cost, but we can save the cost of registering and unregistering mutation
observer and computing common ancestor of the range.

This patch makes HTMLEditRules::PinSelectionToNewBlock() use StaticRange
instead of nsRange for comparing a point and a range (i.e., the DOM tree
won't be changed during it's alive). Unfortunately, we still have allocation
cost, but we can save the cost of registering and unregistering mutation
observer and computing common ancestor of the range.

EditorSpellCheck clones nsRange instance only for temporary use during
initialization even though the DOM tree won't be changed during it. In this
case, using StaticRange is better since it does not need to observe the
DOM tree mutation. I.e., we can save the cost of registering and
unregistering the mutation observer.

I think that we should land part.1 ~ part.5 first. Then, part.6 and part.7 should be landed separately for making it easier to look for regression-window.

https://groups.google.com/forum/#!topic/mozilla.dev.platform/S8WEan1uLGo

https://hg.mozilla.org/mozilla-central/rev/feb8bd2e7973
https://hg.mozilla.org/mozilla-central/rev/610d62589b4e
https://hg.mozilla.org/mozilla-central/rev/bcfd386d2585
https://hg.mozilla.org/mozilla-central/rev/762824a037ce

https://hg.mozilla.org/mozilla-central/rev/f81be4a7864d
https://hg.mozilla.org/mozilla-central/rev/446927a94617

https://hg.mozilla.org/mozilla-central/rev/c8756efe2b0d