Closed Bug 1490126 Opened 2 years ago Closed 1 year ago

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


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




Tracking Status
firefox64 --- affected


(Reporter: twisniewski, Unassigned)



(Whiteboard: [webcompat])


(1 file)

Attached file 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).
Flags: webcompat?
Masayuki probably knows why we do this.
Component: DOM → Editor
Flags: needinfo?(masayuki)
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.
Blocks: 1318312
Flags: needinfo?(masayuki)
OS: Unspecified → All
Hardware: Unspecified → All
Priority: -- → P3
Closed: 1 year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1436906
Component: Editor → Selection
You need to log in before you can comment on or make changes to this bug.