1490126 - Firefox scrolls to a contenteditable item when addRange selects it, even if it is immediately removed from the document. Chrome does not.

Status: RESOLVED DUPLICATE of bug 1436906

(Core :: DOM: Selection, defect, P3)

Description

[Thomas Wisniewski [:twisniewski]]

Attachment: testcase.html

In the attached testcase, a contenteditable element is added to the document, is made part of the document's selection with addRange, then removed.

Blink and WebKit do not bother scrolling the element into view, given that it is removed right away. Firefox does.

It seems that such code is used by live sites to do feature detection, which causes their pages to scroll down mysteriously upon page-load in Firefox.

For interop, it may be worth delaying until the next event loop before attempting to scroll, and only doing so if the element remains attached to the document at that stage (at least that superficially appears to be what Chrome is doing).

Comment 1

[Andrew Overholt [:overholt]]

Masayuki probably knows why we do this.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

Current behavior was introduced by bug 1318312. Chrome sets focus to a contenteditable element when it gets selection range. We need to do same behavior for web-compat. IIRC, Chrome does not scroll to focused editor in this case, but we do it because scrolling to new focused element is our traditional behavior.

Perhaps, we still need to move focus synchronously for execCommand etc, however, it might be possible to put off scrolling to the editor to the next event queue. If JS removes all selection ranges like the testcase, we should stop scrolling.