gemini.google.com - Typing inside the main prompt input (contenteditable) causes the cursor/caret to collapse to the beginning of the current line when canceling a dead-key accent (Mac OS)
Categories
(Web Compatibility :: Site Reports, defect, P2)
Tracking
(Webcompat Priority:?, Webcompat Score:6)
People
(Reporter: rbucata, Unassigned, NeedInfo)
References
()
Details
(Keywords: webcompat:needs-diagnosis, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs][webcompat:sightline][webcompat:japan][webcompat:core][autowebcompat:processed][autowebcompat:repro-failed])
User Story
autowebcompat-repro-status:failed autowebcompat-repro-reason:unsupported_desktop_os platform:windows,mac,linux impact:annoyance configuration:general affects:all branch:release diagnosis-team:dom user-impact-score:300 autowebcompat-repro-report-os:macos
Environment:
Operating system: Mac OS X 10.15
Firefox version: Firefox 157.0
Steps to reproduce:
- Open https://gemini.google.com/ on Firefox for macOS.
- In the prompt field, type a multi-line sentence.
- Press the acute accent key (´) to enter dead key composition state.
- Immediately press Backspace before typing any vowel.
Expected Behavior:
The pending dead-key accent is canceled, and the cursor stays at the current insertion point.
Actual Behavior:
The cursor loses its position and jumps to the beginning of the current line. Any subsequent Backspace keystrokes start deleting text from the start of that line instead of the original insertion point.
Notes:
- Reproduces regardless of the status of ETP
- Reproduces in firefox-nightly, and firefox-release
- Does not reproduce in chrome
- Appears to be an event synchronization conflict between macOS NSTextInputContext composition cancelation and Gecko's Selection anchor offset calculation in contenteditable.
Created from https://github.com/webcompat/web-bugs/issues/236948
|
Reporter | |
Comment 1•1 day ago
|
||
This was reproduced on a macOS 27 M1 device, but not on a macOSX 10.15 device
|
||
Updated•1 day ago
|
|
|
||
Updated•1 day ago
|
|
||
Updated•1 day ago
|
|
||
Updated•1 day ago
|
|
||
Updated•1 day ago
|
|
|
||
Updated•1 day ago
|
|
|
||
Updated•1 day ago
|
|
||
Comment 2•23 hours ago
|
||
I can't reproduce this on Windows. Comment 1 also mentioned this reproducible only to certain MacOS versions.
These fields in User Story don't seem to align with the report and the situation:
platform:windows,mac,linux
configuration:general
affects:all
Masayuki, any quick thoughts on where this needs tweak for is there any log that the QA or reporter can capture for us?
|
|
||
Updated•23 hours ago
|
|
|
||
Comment 3•18 hours ago
|
||
(In reply to Hsin-Yi Tsai (she/her) [:hsinyi] from comment #2)
I can't reproduce this on Windows. Comment 1 also mentioned this reproducible only to certain MacOS versions.
These fields in User Story don't seem to align with the report and the situation:
platform:windows,mac,linux
configuration:general
affects:all
Seems to not reproducible on Linux, either. Seeing the issue also on MacOS M4.
Therefore, I am asking for re-triaging the webcompat priority/impact.
Masayuki, any quick thoughts on where this needs tweak for is there any log that the QA or reporter can capture for us?
|
||
Comment 4•18 hours ago
|
||
Can see a different unexpected behavior on Windows in German keyboard (normal textbox would render backtick as-is on backspace, while Gemini doesn't do that and treats it as a backspace without backtick). But that happens on Chrome too.
|
||
Comment 5•6 hours ago
|
||
According to comment 1, it may be caused by a behavior change of macOS's dead key. I've not checked what's changed in the new version yet.
|
|
||
Comment 6•6 hours ago
|
||
I wonder if this is reproducible with simple contenteditable element.
Description
•