Closed Bug 1490126 Opened 2 years ago Closed 1 year ago
Firefox scrolls to a contenteditable item when add
Range selects it, even if it is immediately removed from the document . Chrome does not .
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).
Masayuki probably knows why we do this.
Component: DOM → Editor
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.
OS: Unspecified → All
Hardware: Unspecified → All
Status: NEW → RESOLVED
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.