1773810 - Cannot change line, cursor stays in place

Status: RESOLVED DUPLICATE of bug 1774697

(Core :: Layout, defect)

Description

[Andreas Stavropoulos]

Attachment: mookee.png

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

Steps to reproduce:

Upon visiting the page https://mookee.apifon.com/#/dashboard/ choosing to send a quick message (SMS), then trying to type in the box at the bottom right the text for the message to be send.

Actual results:

If you try to change line either by using the direction arrows or by just clicking in another line, the cursor remains in place.

Expected results:

Cursor should move on both use of direction arrows and click.

Comment 1

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

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

Comment 2

[David Shin[:dshin]]

Can't confirm this at the moment, since the page is behind login, and I imagine a paywall.

A few questions/request:

• Have you had this happen with previous version(s) of Firefox?
• If you are able to save to select File - Save As, and save that page as Web Page, complete, are you able to reproduce the issue with the saved web page?
• If you are able to reproduce with the saved file above, and if you're sure that there is no personal information, are you ok with posting the page (Probably Dashboard.html & a directory called Dashboard_files) as a ZIP file? If you're comfortable with editing HTML files, you can redact any personal info. Otherwise, if you're ok with it, you can email it to me so that the bug can be confirmed.

Comment 3

[Andreas Stavropoulos]

Attachment: Dashboard.htm

Comment 4

[Andreas Stavropoulos]

Attachment: Dashboard_files.rar

Comment 5

[Andreas Stavropoulos]

• I had this issue with all previous versions.
• I could not save the web page to reproduce the issue.
• Let me know if you want me to email you the credentials.

Comment 6

[Andreas Stavropoulos]

(In reply to Andreas Stavropoulos from comment #5)

• I had this issue with all previous versions.
• I could not save the web page to reproduce the issue.
• Let me know if you want me to email you the credentials.

I did upload the files I could save but I couldn't reproduce the page with them.

Comment 7

[David Shin[:dshin]]

Attachment: Testcase

Thank you for the assist! I've reduced the testcase on nightly.
The page sets user-select: none; to :hover elements. This causes us to fall into a state where:

• You can input text just fine
• You can delete text with backspace just fine - if you hold down backspace when the cursor is at the end, it will delete everything
• You can delete text with delete, but only within the line the cursor is in.
• You cannot move the cursor by clicking on any text while textarea is in focus.
• You can move using left and right arrow keys, but only within the cursor is in.
• You can press up to go to the very beginning of the input, and down to go to the very end of the input.
• Clicking in from out of focus has some chance of initiating a drag selection from the last cursor's position to that of current position, or some chance of just letting you select the location you want.

Andreas, for a workaround, you can try to click outside the textbox, then at the text location you want. Right clicking on the textbox then opening up the inspector tool, then adding user-select: auto; to element style is also an option if you're comfortable with devtools.

Comment 8

[David Shin[:dshin]]

Attachment: Testcase

Comment 9

[David Shin[:dshin]]

Attachment: Better testcase showing focus status

Comment 10

[Daniel Holbert [:dholbert]]

This might be the same thing discussed in https://github.com/webcompat/web-bugs/issues/22784 and https://bugs.chromium.org/p/chromium/issues/detail?id=340671

Note that Safari/WebKit has behavior that's not-quite-the-same, but similar to us here (though it looks like they only support prefixed -webkit-user-select and don't parse user-select)

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (with -webkit prefixed style and with text already present in textarea)

Comment 12

[Daniel Holbert [:dholbert]]

In Safari/WebKit, you can't even edit testcase 2, really; sometimes Backspace works and clears the whole textarea, but generally it doesn't behave like an editable/selectable area.

See also bug 477152.

Comment 13

[Daniel Holbert [:dholbert]]

https://github.com/webcompat/web-bugs/issues/22784#issuecomment-447699561 has a good summary around the history of "user-select:none". It's a bit of a mess. It's essentially expressing an intent from the web developer that text shouldn't be selectable, so our behavior here is essentially honoring that request.

I suspect Safari has the same symptoms or worse on the original page here, given how they handle my attached testcase 2 here, and given that the attached RAR file has -webkit-user-select: none (which I think is sufficient to trigger the Safari behavior).

Andreas, if you happen to have Safari available to test, it might be interesting to confirm that they're similarly-broken (or possibly more-broken) here.

The fact that Chrome "works" here is kind of a bug (i.e. they're disregarding the user-select:none request from the web developer), and that's tracked in https://bugs.chromium.org/p/chromium/issues/detail?id=340671 . Though perhaps we should similarly break our implementation as well? It's pretty weird that sites are using this style in this way; I wonder what they're trying to do.

(In reply to David Shin[:dshin] from comment #7)

Andreas, for a workaround, you can try to click outside the textbox, then at the text location you want. Right clicking on the textbox then opening up the inspector tool, then adding user-select: auto; to element style is also an option if you're comfortable with devtools.

You can get a more persistent workaround using this add-on:
https://addons.mozilla.org/en-US/firefox/addon/styl-us/
...which lets you add custom styles for certain sites. So for example, at the site in question, you could use the Stylus add-on to add a style for that domain (using the option in its toolbar-button-menu) and just add the style textarea { user-select: auto !important } or something like that.

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #13)

The fact that Chrome "works" here is kind of a bug (i.e. they're disregarding the user-select:none request from the web developer), and that's tracked in https://bugs.chromium.org/p/chromium/issues/detail?id=340671 . Though perhaps we should similarly break our implementation as well? It's pretty weird that sites are using this style in this way; I wonder what they're trying to do.

Actually it looks like the spec does call out editable elements as a special case here, so Chrome is correct.

I spun off bug 1774697 to make that change, and I think that would fix this issue here (though I assume/suspect the site will remain broken in Safari).

Comment 15

[Daniel Holbert [:dholbert]]

I'm going to mark this as a duplicate of bug 1774697, since I think we've got a pretty good encapsulation of what specifically needs to happen & why in the first couple of comments there, and I'm confident that'll fix this issue. (We should double-check to be sure, once we've fixed bug 1774697, though.)