Relevant profile: https://share.firefox.dev/3tZv0Dh. It indicates removing ranges is slow. It's because calls of `nsTextFrame::SelectionStateChanged` are expensive. ``` nsTextFrame::SelectionStateChanged(unsigned int, unsigned int, bool, mozilla::SelectionType) mozilla::dom::Selection::SelectFrames(nsPresContext*, nsRange*, bool) const mozilla::dom::Selection::RemoveRangeAndUnselectFramesAndNotifyListeners(nsRange&, mozilla::ErrorResult&) mozInlineSpellChecker::RemoveRange(mozilla::dom::Selection*, nsRange*) ``` This issue occurs, when the spellchecker runs out of time when checking "foo/bar/x.html". When "foo" is the last checked word, in the next time slice, it starts checking at "foo" again, removing the existing ranges for "foo" and "bar" and again adding them. Jumping back to "foo" seems necessary, because the spellchecker treats "/" differently than a blank, because the former might appear as part of a URL. The right fix here seems to be: when jumping back, don't remove the existing ranges, but only remove them if they wouldn't be added immediately afterwards. In practice, there should always be time slices when the text doesn't change, resulting in no removing and adding of existing ranges. Therefore always proceeding in the words to check, hence not endlessly scheduling new spellcheckings.
Bug 1687263 Comment 22 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Relevant profile: https://share.firefox.dev/3tZv0Dh. It indicates removing ranges is slow. It's because calls of `nsTextFrame::SelectionStateChanged` are expensive. ``` nsTextFrame::SelectionStateChanged(unsigned int, unsigned int, bool, mozilla::SelectionType) mozilla::dom::Selection::SelectFrames(nsPresContext*, nsRange*, bool) const mozilla::dom::Selection::RemoveRangeAndUnselectFramesAndNotifyListeners(nsRange&, mozilla::ErrorResult&) mozInlineSpellChecker::RemoveRange(mozilla::dom::Selection*, nsRange*) ``` This issue occurs, when the spellchecker runs out of time when checking "foo/bar/x.html". When "bar" is the last checked word, in the next time slice, it starts checking at "foo" again, removing the existing ranges for "foo" and "bar" and again adding them. Jumping back to "foo" seems necessary, because the spellchecker treats "/" differently than a blank, because the former might appear as part of a URL. The right fix here seems to be: when jumping back, don't remove the existing ranges, but only remove them if they wouldn't be added immediately afterwards. In practice, there should always be time slices when the text doesn't change, resulting in no removing and adding of existing ranges. Therefore always proceeding in the words to check, hence not endlessly scheduling new spellcheckings.