text cursor positioning issues in textarea
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
People
(Reporter: vincent-moz, Unassigned)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0
Steps to reproduce:
- I started to report an issue at https://www.austingroupbugs.net/bug_report_page.php (Online Pubs project chosen in the top-right menu).
- While I forgot to fill the "Desired Action" textarea, I submitted the issue.
- I got an error from the web site because I did not fill the "Desired Action" textarea. So I clicked on the Back button as suggested.
- I started to fill the "Desired Action" textarea.
Actual results:
At this time, when I wanted to edit my report, I noticed issues with the positioning of the text cursor in both "Description" and "Desired Action" textareas:
- Clicking somewhere to change the cursor position in the same textarea did not work in general: the cursor was staying at the same position. However, clicking somewhere in the other textarea always put the cursor at the wanted position.
- Moving the cursor with the arrow keys did not work in general: most often, the cursor was staying at the same position, but it sometimes jumped to the end of the textarea.
Note that entering new text was always working, IIRC.
This occurred for the submission of https://www.austingroupbugs.net/view.php?id=1856 but I cannot reproduce the problem when I try to edit another form at the above URL.
Expected results:
The cursor should move as expected.
|
||
Comment 1•11 months ago
|
||
Hmm, that's interesting, but I don't have access to this page. It looks like a focus issue (though it might be in layout).
Are you aware of somewhere publicly-accessible where I could try to reproduce something like that? Is it consistently reproducible for you?
Thank you.
|
Reporter | |
Comment 2•11 months ago
|
||
I can't reproduce the issue.
The page has standard textarea's (unlike many websites). In the source, I can see a few JS scripts:
<script type="text/javascript" language="JavaScript"><!--
if(document.layers) {document.write("<style>td{padding:0px;}<\/style>")}
// --></script>
and
- https://www.austingroupbugs.net/javascript/common.js
- https://www.austingroupbugs.net/javascript/ajax.js
in head, and later
<!-- Autofocus JS -->
<script type="text/javascript" language="JavaScript">
<!--
window.document.report_bug_form.category.focus();
-->
</script>
|
||
Comment 3•11 months ago
|
||
Thank you for your bug report! We can't make any progress on this without a way to reproduce the issue. If this happens again please reopen this, or file a new bug.
|
|
Reporter | |
Comment 4•10 months ago
|
||
I'm reopening the bug as I'm having the same problem on another website (assistance.ens-lyon.fr but it is private) with a single-line input. This seems to just be a display issue: the cursor bar remains at the same position, but when I enter text, the text appears where I clicked (thus not where the cursor bar appears).
The problem occurs only when I click while the form input already has the focus (so this matches what I've said in my original bug report). If I click somewhere else to remove the focus from the input, then click again somewhere in the input, the cursor appears at the right position. A second click in the input yields the issue.
The cursor keys do not change the position of the cursor bar, but they are taken into account if I enter text (which appears where te cursor should be).
This time, this is Firefox 131.0.2.
|
|
Reporter | |
Comment 5•10 months ago
|
||
I've attached a video showing the issue:
- I click at the end of the input.
- I type "12", which appears as expected, and type Backspace twice.
- I type the Left key several times (but the cursor bar does not move).
- I type "12", which appears where the cursor should be; the cursor bar moves 2 characters to the left.
- I type Backspace twice, which removes "12", and the cursor bar is back at the end of the text.
- I repeat steps 3-5.
I can also reproduce this issue. It seems to be specific to Linux, or at least, I have never seen this problem on macOS but I have encountered it with some regularity on Linux (Kwin 5.27.11, Wayland). When it is triggered, it seems to affect only the inputs on a single page (other tabs and the address bar seem to keep working correctly). Reloading the affected page seems to fix things.
I feel like the bug may be some state management bug in text selection management code, possibly related to modifier key state. When glitched, selecting some text and then pressing Ctrl+C to copy causes the text selection to visually clear, as if I had pressed a key that would have replaced the selection.
I do not know what the specific triggering condition is. I have tried quite a bit to mash keys until Firefox breaks with no luck. I have seen this happen with at least GitHub comments and one other site.
|
||
Comment 7•10 months ago
|
||
hmm, sounds like this is same as bug 1924093, but I've never seen this bug on Windows. focus/selection code is almost completely cross-platform code. So, something wrong in Graphics or something else.
After some more recent experiences with a different React app where I definitely hadn’t touched modifier keys recently, I don’t think it’s related to modifier key state any more, though I guess there could be a different second bug there.
One of the more interesting manifestations of this bug I encountered today is, after clicking on a themed (clipped and 1x1 sized) <input type="checkbox">, when the focus moved away from the bugged textarea to the checkbox, the text cursor was drawn at the position of the checkbox.
I agree that bug 1924093 seems related/the same. I have not seen this in my own window chrome yet, but I don’t see why it wouldn’t happen there too since it is just another web page.
|
||
Comment 9•10 months ago
|
||
Hi Martin, the comments from the reporter or other affected users seem to hint that this is a linux specific problem. Does it ring any bell?
|
|
||
Updated•10 months ago
|
|
||
Comment 10•9 months ago
|
||
Hi,
I can report that I have now also seen this happen in the browser address bar. Smilefrown.
When the visible cursor is in the broken state, at least sometimes it is still responding to keyboard input and is acting like it has a broken view of the actual layout/text content of the input. So, for example, adding/deleting characters may cause the cursor to move in a backward direction, or using arrow keys to navigate may cause the cursor to visually jump quite a long distance and end up in another wrong position.
As far as fixing the problem goes: I am occasionally considered by some to be a passable software engineer, but the Firefox codebase is… big. So, if someone with more experience could point in a broad direction based on this description of the problem, I can look in Searchfox to see if I can find anything that looks questionable. (I’m stopping short of saying I’ll try to debug it interactively because there’s no consistent trigger condition and I’m not quite ready to commit to compiling a whole web browser from scratch. :-))
Thanks,
|
|
||
Comment 11•9 months ago
|
||
If this is a recent regression, we'd be really happy if somebody who can reproduce this bug get the regression range with mozregression.
|
|
||
Comment 12•9 months ago
|
||
Unfortunately, I started experiencing this after switching from macOS to Linux, rather than after a Firefox update on Linux, so there’s no chance of regression testing by me. I have not been able to create a reproducer either, so I am starting to think that a race condition is involved. If there’s a log module for OS events (in particular, keyboard and focus), let me know, since that could be a different way into some insight into what happens right before things break, since I know at least once in a day the problem is likely to show up.
Really, I’d like to do some digging in Searchfox at the code that specifically deals with the visible cursor but I’m not exactly sure where it is specifically. Maybe IMContextWrapper.cpp or NativeKeyBindings.cpp? There is some related stuff in nsLookAndFeel.cpp too. Unfortunately me trying to do a code search is partially frustrated by the fact that “cursor” also refers to mouse cursor in UI code, not just the text caret/insertion-point, so the search results are ambiguous and require extra effort to deduce from context.
Thanks,
|
|
Reporter | |
Comment 13•9 months ago
|
||
The issue is quite rare for me and I cannot find a reproducer either, so that using mozregression is impossible for me. I also think that it may be a race condition. It might also be due to some kind of unknown combination of conditions. Getting debug information would be useful, but since the issue is rare, this has to be done over a long period (several days or weeks), without significant drawbacks. If this is a race condition, one should hope that debug logging will not make the issue disappear (seen that various times before).
|
|
||
Comment 14•9 months ago
|
||
(In reply to Vincent Lefevre from comment #13)
The issue is quite rare for me and I cannot find a reproducer either, so that using mozregression is impossible for me. I also think that it may be a race condition.
Any chance you happen to have a rough idea of when the problem started? That would allow a faster review of commit history.
Getting debug information would be useful, but since the issue is rare, this has to be done over a long period (several days or weeks), without significant drawbacks.
It looks like there is a log module IMEHandler that appears to track what I asked about. There is a comment with usage recommendation:
// For collecting other people's log, tell `MOZ_LOG=IMEHandler:4,sync`
// rather than `MOZ_LOG=IMEHandler:5,sync` since using `5` may create too
// big file.
The IMEHandler:4,sync can go to about:logging and enabled on demand.
After the problem occurs, it seems plausible that enabling IMEHandler log will show what’s failing. We’ll see!
Best,
|
|
Reporter | |
Comment 15•9 months ago
|
||
(In reply to Colin S from comment #14)
Any chance you happen to have a rough idea of when the problem started? That would allow a faster review of commit history.
I noticed it for the first time at the time I reported the bug, on 2024-09-10. I upgraded Firefox from 129 to 130 on 2024-09-05. So the bug may have appeared in Firefox 130, but I'm not 100% sure.
|
|
||
Comment 16•7 months ago
|
||
Hello,
I was able today to capture an IMEHandler log of this failure. In the attached log, I focus a text area which is working correctly, type "test", unfocus/refocus the window (which breaks the text area), then type "broken".
Additionally, I somehow lucked out and had the failure happen with two tabs at the same time. The two broken tabs were in separate child processes according to about:processes, so it is not a single child process that is broken.
The trigger for breaking the text area is to unfocus & refocus the Firefox window. Refocusing the control itself is OK; switching to another tab and returning is also OK. Closing and unclosing a tab with a broken text area causes the text area to work OK only until the window is unfocused, at which point it is broken again. Moving the window itself does not fix the broken text area. Moving the broken tab to a new window does permanently fix it; the text area continues to work after returning the now-fixed tab back to the original window. Moving a tab only fixes the text area in that tab; the text area in the other broken tab remains broken.
I may trigger this issue more frequently than others because I have a global keybinding for clipboard history at ctrl+shift+v which causes the Firefox window to unfocus while editing.
Best,
|
|
||
Comment 17•7 months ago
|
||
Apologies for the bug-spam but I spoke too soon about what is responsible for fixing the text area. I tried the same thing of moving the second broken tab to another window and it remained broken. What a confusing bug.
One final thing I can add is that the brokenness of the text area persists through bfcache. When I navigated to another page and then went back to the broken page with the back button, the text area was still broken. The text area on the new page I had navigated to was working fine, so it also seems specific to the particular page state.
Best,
|
|
Reporter | |
Comment 18•7 months ago
|
||
Note that in my case, I use the FVWM manager, with focus following the mouse, i.e. each time the mouse pointer enters a window, the window automatically gets the focus (except when a menu is open or some particular application grabs the focus). Moreover, I recall that the issue occurs quite rarely for me. IIRC, it has not occurred for several weeks now.
|
||
Updated•7 months ago
|
|
|
||
Updated•7 months ago
|
|
|
Reporter | |
Comment 19•5 months ago
|
||
With Firefox 135.0.1, the bug was occurring in an IMDb contribution form, for keyword additions, in any keyword area. It stopped occurring when I did a "Re-check these updates" (which basically loads an updated version of the page).
|
||
Comment 20•4 months ago
|
||
I encountered this bug today, and as indicated in comment 16, moving the tab to a freshly opened window caused the textarea to become unglitched. The textarea remained unglitched after moving the tab back to its original window.
It is not clear from comments here or from my own testing what the trigger is. Comment 16 suggested that "The trigger for breaking the text area is to unfocus & refocus the Firefox window". Unfocusing and refocusing the window did not break any textarea for me.
Like Colin S, I am also running firefox under kwin, but under X11. I do wonder if this is related and how many other users seeing this bug are also using KDE.
I only started seeing this recently. Before I started seeing this bug, I was experiencing both bug 1881136 and bug 1876366 (i.e. the mouse cursor remained an arrow when hovering over a link or hovering over a textarea). After a recent reboot, mouse cursors are working again, and within a few days of rebooting I started experiencing the textarea cursor effects described here. Per my notes, I may have had widget.gtk.legacy.cursors.enabled set prior to the reboot. It is currently false. Does text cursor drawing relate at all to mouse cursor drawing, or is it a mere coincidence that (for me) one problem stopped when the other problem started?
|
|
Reporter | |
Comment 21•4 months ago
|
||
I've just reported a reproducible bug with a similar effect: bug 1959944. This is also a caret (text cursor) displayed at an incorrect position. But there, drag-and-drop is involved, and the issue is more severe, as it does not seem possible to get rid of it in the page once it has occurred. However, a fix of this bug 1959944 might have an effect on the reproducibility of the above issue.
Description
•