1955040 - Cursor loses focus when editing web pages in developer tools

Status: RESOLVED FIXED

(DevTools :: Inspector, defect, P2)

Description

[Kiddy]

Attachment: 2025-03-19 23-46-53-105.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0

Steps to reproduce:

Step 1: Visit https://egs.stcn.com/news/index.html
Step 2: Press F12 to open Developer Tools
Step 3: Double click on the element below body to enter edit mode

Actual results:

After a few seconds of entering edit mode, the edit mode is disabled, the cursor is lost, no text can be entered, and the entire current element is automatically selected.
Strangely enough, when double-clicking to edit an "html" element, the cursor is not lost.

Expected results:

The cursor should not be lost when entering edit mode, and should not automatically select the entire element.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Sean Feng [:sefeng]]

Yeah..I can reproduce this. This seems like a devtools issue.

Comment 3

[Julian Descottes [:jdescottes]]

Looks like there is a subtree modification on the body element, and after this we re-render the whole markup view. We should handle this more gracefully.

First step is to have a reduced test case here.

Comment 4

[Nicolas Chevobbe [:nchevobbe]]

simpler STR:

• Go to data:text/html,<meta charset=utf8><script>setInterval(() => document.body.append(document.createTextNode("hello")), 2000)</script><h1>hello
• Open the inspector
• Double click on the <h1> node

-> after a couple seconds, a node is added to the body and the focus is removed from the h1 input

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

I'm not 100% positive I have this right, but this seems to come from https://searchfox.org/mozilla-release/rev/2386158942e52a22ae33faa889b42944862d83c4/devtools/client/inspector/markup/markup.js#2327-2328,2342,2344,2347-2352,2363

const updatePromise = this._getVisibleChildren(container, centered)
  .then(children => {
...
    const fragment = this.doc.createDocumentFragment();
...
    for (const child of children.nodes) {
...
      fragment.appendChild(childContainer.elt);
    }

    while (container.children.firstChild) {
      container.children.firstChild.remove();
    }
...
    container.children.appendChild(fragment);

when there's a new element in a node, we get all the previously existing containers, append them in a fragment, so the element is actually removed from the document, and the focus is moved to its parent (I guess).
Then the fragment is appended, which adds the node back, but we lost the focus state in the meantime

Comment 6

[Nicolas Chevobbe [:nchevobbe]]

Okay, looks like I was right. We can do some checks to see if the focused element was moved and added back, and re-focus it again:

diff --git a/devtools/client/inspector/markup/markup.js b/devtools/client/inspector/markup/markup.js
--- a/devtools/client/inspector/markup/markup.js
+++ b/devtools/client/inspector/markup/markup.js
@@ -2341,9 +2341,14 @@ MarkupView.prototype = {
 
         const fragment = this.doc.createDocumentFragment();
 
+        const activeElement = this.doc.activeElement;
+        let setFocusElementAgain = false;
         for (const child of children.nodes) {
           const slotted = !isShadowHost && child.isDirectShadowHostChild;
           const childContainer = this.importNode(child, flash, slotted);
+          if (childContainer.elt.contains(activeElement)) {
+            setFocusElementAgain = true;
+          }
           fragment.appendChild(childContainer.elt);
         }
 
@@ -2361,6 +2366,12 @@ MarkupView.prototype = {
         }
 
         container.children.appendChild(fragment);
+        if (
+          setFocusElementAgain &&
+          container.children.contains(activeElement)
+        ) {
+          activeElement.focus();
+        }
         return container;
       })
       .catch(this._handleRejectionIfNotDestroyed);

I'll work on some tests and make sure this is not breaking anything

Comment 7

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1955040 - [devtools] Restore focus to previously focused element in MarkupView#_updateChildren. r=#devtools.

When there's a new element in a (parent) node, all its still existing children
containers are added in a fragment that is then back re-added in the document.
Doing so, elements are removed from the document, and if the focus was set in
one of those element, it's moved to its still-in-the-tree ancestor.

This patch adds some logic to restore the focus on the previsouly focused element
so we don't disturb user keyboard navigation/editing.

A test case is added to cover this.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4070421bb539
[devtools] Restore focus to previously focused element in MarkupView#_updateChildren. r=devtools-reviewers,ochameau.

Comment 9

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/4070421bb539

Comment 10

[Kiddy]

I tested [https://ftp.mozilla.org/pub/firefox/nightly/2025/04/2025-04-08-21-22-25-mozilla-central/firefox-139.0a1.en-US.win64.zip] and found a new BUG.

When in the editing state, if you slide the scroll bar down, it will slide back to the editing position after a few seconds.

Comment 11

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Kiddy from comment #10)

I tested [https://ftp.mozilla.org/pub/firefox/nightly/2025/04/2025-04-08-21-22-25-mozilla-central/firefox-139.0a1.en-US.win64.zip] and found a new BUG.

When in the editing state, if you slide the scroll bar down, it will slide back to the editing position after a few seconds.

Can you file a new bug for this so we can look at it please? thanks

Comment 12

[Kiddy]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #11)

(In reply to Kiddy from comment #10)

I tested [https://ftp.mozilla.org/pub/firefox/nightly/2025/04/2025-04-08-21-22-25-mozilla-central/firefox-139.0a1.en-US.win64.zip] and found a new BUG.

When in the editing state, if you slide the scroll bar down, it will slide back to the editing position after a few seconds.

Can you file a new bug for this so we can look at it please? thanks

I think it should be a result of fixing this bug imperfectly, so wouldn't it be easier to still discuss it in the thread?

Comment 13

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Kiddy from comment #12)

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #11)

(In reply to Kiddy from comment #10)

I tested [https://ftp.mozilla.org/pub/firefox/nightly/2025/04/2025-04-08-21-22-25-mozilla-central/firefox-139.0a1.en-US.win64.zip] and found a new BUG.

When in the editing state, if you slide the scroll bar down, it will slide back to the editing position after a few seconds.

Can you file a new bug for this so we can look at it please? thanks

I think it should be a result of fixing this bug imperfectly, so wouldn't it be easier to still discuss it in the thread?

the original bug didn't mention scrolling and was about lost of focus, having a dedicated bug for the scrollbar issue would be better. If the fix for this bug caused the issue, we can create the new bug saying that this is a regression introduced by this bug, so we still have history.

Comment 14

[Nicolas Chevobbe [:nchevobbe]]

I filed Bug 1959358 and will take care of it

Comment 15

[Kiddy]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #14)

I filed Bug 1959358 and will take care of it

Thanks!

Comment 16

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Kiddy from comment #15)

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #14)

I filed Bug 1959358 and will take care of it

Thanks!

thanks for catching the issue :)