Bugzilla

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 styl.us 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.

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.