2032191 - Text cursor (caret) disappears in Gmail compose window after inserting AI-generated text

Status: ASSIGNED

(Core :: DOM: Editor, defect, P1)

Description

[Jeff Muizelaar [:jrmuizel]]

Problem type: Something else
Description: Text cursor (caret) disappears in Gmail compose window after inserting AI-generated text ("Help me write" feature)
Steps to Reproduce:
Summary: Text cursor (caret) disappears in Gmail compose window after inserting AI-generated text ("Help me write" feature)

Steps to Reproduce:

Open Gmail web interface in Firefox (tested with a Google Workspace account that has the "Help me write" AI feature enabled).
Click "Compose" to open a new email.
Click the "Help me write" button (pencil/star icon) in the compose toolbar.
Enter a prompt and let the AI generate text.
Accept/insert the generated text into the email body.
Observe the compose text field.

Expected Behavior:
A blinking text cursor (caret) should be visible in the email body field after the AI-generated text is inserted, indicating the current input position.

Actual Behavior:
No blinking cursor is visible in the email body field. Clicking into the text field does not restore the cursor either. Typing still works — characters appear in the field — but there is no visible caret to indicate the current insertion point.

Notes:

The issue persists until the compose window is closed and a new one is opened.
Typing, selecting text, and other input actions still function correctly; only the visual cursor indicator is missing.
The issue does not occur in Microsoft Edge, suggesting it is Firefox-specific.

Browser Configuration

None

Comment 1

[Jeff Muizelaar [:jrmuizel]]

The cursor comes back for me when I refocus the window

Comment 2

[Jeff Muizelaar [:jrmuizel]]

I can reproduce this in the Mozilla gmail instance. Emilio, any suggestions for where to look about why the caret wouldn't be visible?

Comment 3

[Emilio Cobos Álvarez [:emilio]]

• Check if the editable thing still has focus (if you can type it probably does).
• Check whether we call nsCaret::SetVisible(false) or nsCaret::AddForceHide(). Editor calls the later a couple times.
• If that all seems to be fine I'd look at the display list code (around here)

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I see:

nsCaret::SetVisible(false)
* frame #0: 0x0000000113d04ce8 XUL`nsCaret::SetVisible(this=0x00000001217e12e0, aVisible=false) at nsCaret.cpp:142:27 [opt]
    frame #1: 0x0000000113cbce40 XUL`mozilla::PresShell::SetCaretEnabled(this=<unavailable>, aInEnable=<unavailable>) at PresShell.cpp:2245:15 [opt] [inlined]
    frame #2: 0x0000000113cbce0c XUL`non-virtual thunk to mozilla::PresShell::SetCaretEnabled() at PresShell.cpp:0 [opt]
    frame #3: 0x0000000113ac6b60 XUL`mozilla::EditorBase::FinalizeSelection(this=0x000000012ff57000) at EditorBase.cpp:5944:58 [opt]
    frame #4: 0x0000000113b186a0 XUL`mozilla::HTMLEditor::OnBlur(this=0x000000012ff57000, aEventTarget=0x0000000137c8ce40) at HTMLEditor.cpp:917:17 [opt]
    frame #5: 0x0000000113ad5364 XUL`mozilla::EditorEventListener::Blur(this=0x000000012fc0c1c0, aBlurEvent=<unavailable>) at EditorEventListener.cpp:1179:48 [opt] [inlined]

but no corresponding nsCaret::SetVisible(true)

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Let me try to poke today, but no promises.

Comment 6

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Hi Leo, you are also looking at some caret issues. Mind to taking a loot at this too? Thanks

Comment 8

[Leo Tenenbaum [:ltenenbaum]]

Hmm I think this has something to do with the fact that gmail sets contenteditable=false on the editor while the AI thing is active, and only sets it back to true a bit of time after it is refocused. But I can't reproduce this behavior in a smaller test case… I'll keep investigating :)

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Yeah, I saw the same thing

Comment 10

[Leo Tenenbaum [:ltenenbaum]]

Attachment: minimal example

Yes okay Document::EditingStateChanged can enable the caret (through MakeWindowEditable) but it returns early if the editing state doesn't change (and it looks like the editing state is always EditingState::eContentEditable if there is at least one contenteditable element on the page). So if a focused element becomes editable and there is any other editable element in the document then the caret is not enabled.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

(In reply to Leo Tenenbaum [:ltenenbaum] from comment #10)

Created attachment 9570674 [details]
minimal example

Nice. Any idea how easy it is to fix?

Comment 12

[Leo Tenenbaum [:ltenenbaum]]

I think I have a working patch… But changing editor stuff is always risky so let's see what try thinks…

Comment 13

[Leo Tenenbaum [:ltenenbaum]]

Attachment: Bug 2032191 - Return false in EditorBase::CanKeepHandlingFocusEvent if focused element is not editable. r=masayuki

Comment 14

[Jeff Muizelaar [:jrmuizel]]

Leo, do you agree that Google should be able work around this by making the element contentEditable before focusing it?

Comment 15

[Leo Tenenbaum [:ltenenbaum]]

Yes, that would work

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4af36fb85003
https://hg.mozilla.org/integration/autoland/rev/6a0dd14ffd76
Return false in EditorBase::CanKeepHandlingFocusEvent if focused element is not editable. r=masayuki

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6ecc579ec52b
https://hg.mozilla.org/integration/autoland/rev/15c8e3db5483
Revert "Bug 2032191 - Return false in EditorBase::CanKeepHandlingFocusEvent if focused element is not editable. r=masayuki" for causing caret related failures.

Comment 18

[Cosmin Sabou [:CosminS]]

Backed out for causing caret related failures.

Push with failures

Failure logs:

• https://treeherder.mozilla.org/logviewer?job_id=561241408&repo=autoland&task=SZCe4W7lSLi_K-Y-wz-Fpw.0
• https://treeherder.mozilla.org/logviewer?job_id=561217765&repo=autoland&task=EQ79vMNlQiaHYnEqlPP_BQ.0
• https://treeherder.mozilla.org/logviewer?job_id=561249501&repo=autoland&task=DWuC_ox2RSqFgDiDR0gWpQ.0

Backout link

Comment 19

[Leo Tenenbaum [:ltenenbaum]]

Hmm it looks like the problem is that we are no longer changing the selection when focusing a <textarea> for the first time. It looks like TextEditor::OnFocus doesn't update the document's selection because TextEditor uses its own selection controller (unlike HTMLEditor). I'm just trying to figure out what is the best way of fixing this…

Comment 20

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/59373 for changes under testing/web-platform/tests

Comment 21

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/3e98c374c410
https://hg.mozilla.org/integration/autoland/rev/239224c16fe9
Return false in EditorBase::CanKeepHandlingFocusEvent if focused element is not editable. r=masayuki

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/8db98c5af2fb
https://hg.mozilla.org/integration/autoland/rev/7e84f9f42418
Revert "Bug 2032191 - Return false in EditorBase::CanKeepHandlingFocusEvent if focused element is not editable. r=masayuki" for causing wr failures @nsINode.cpp.

Comment 24

[agoloman]

Backed out for causing wr failures @nsINode.cpp.

• Backout link
• Push with failures
• Failure Log
• Failure Log ba @browser_text_selection.js
• Failure log @test_named_deck.html

Comment 25

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/59525 for changes under testing/web-platform/tests

Comment 26

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5a8dadf61348
https://hg.mozilla.org/integration/autoland/rev/f033614b72fd
Return false in EditorBase::CanKeepHandlingFocusEvent if focused element is not editable. r=masayuki

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/527e77160d1e
https://hg.mozilla.org/integration/autoland/rev/a8ec6a655f40
Revert "Bug 2032191 - Return false in EditorBase::CanKeepHandlingFocusEvent if focused element is not editable. r=masayuki" for causing ba failures @ browser_text_selection

Comment 29

[amarc]

Backed out for causing ba failures

• Backout link
• Push with failures
• Failure Log

Comment 30

[Leo Tenenbaum [:ltenenbaum]]

Ah, we no longer set selection to an <a> when it is focused. But we still use the old behavior if caret browsing is enabled, so it should be enough to enable it for that test.
Hopefully this is the last failure!