477152 - Do not expose -moz-user-select/-webkit-user-select to content (user hostile)

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

I can't select text on this page:

http://www.sheahomes.com/main.cfm?dir=findahome&sec=none&subsec=directions&temp=communityother&communityid=570

Not sure why, or really what component to file against.

Using Gecko/20090205 Shiretoko/3.1b3pre, tested on both OS X and Windows Vista.

Comment 1

[Mycroft Project (CC)]

disabling http://www.sheahomes.com/css/dhtml-horiz.css seems to enable selection...

Comment 2

[Mycroft Project (CC)]

sorry, wrong bit of css but it's in there somewhere

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

So do we provide a way for web developers to actively block people selecting text on their pages, or is this a bug?  The text is selectable in Chrome, Safari and IE, so I assumed the problem was on our side (either way I think we should give the user more control than the web developer).

Comment 4

[Mycroft Project (CC)]

guessing:
td {-moz-user-select:	none;} .selected {background:	Highlight;color:HighlightText;}

in:
http://www.sheahomes.com/css/sh_page_styles.css

apparently:
https://developer.mozilla.org/En/CSS/-moz-user-select

( I don't count as we but I'll agree that it's pretty ugly as is)

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

dbaron in dev.platform explains:

>So user-select was dropped from css3 modules (along with a few other
>related properties), because it was deemed to be a bad idea and/or
>hard to fit with the rest of the CSS model (since properties
>shouldn't be able to influence whether selectors match).  I'm
>actually not entirely sure of the details.
>
>But we implemented -moz-user-{focus,input,modify,select}, and
>changed them a good bit from what was ever proposed in any CSS
>drafts, and have a whole bunch of dependencies on them.
>
>It might actually be a good idea not to expose them to content; I'm
>not sure how much they're used in the wild, though.

I'm morphing the bug to not expose -moz-user-select to content, since this both takes away control from the user, and isn't really a web standard that we want people developing against.

Comment 6

[Benjamin Smedberg]

I disagree. Often when a website has content and navigation items, it makes sense for the navigation items not to be selectable. I think we should keep this property available to all. If wanted, we could allow users to disable it, either via prefs, or via an extension or direct edits to usercontent.css

Comment 7

[Uwe Schröder]

Even adding { -moz-user-select: normal !important; } to userContent.css still leaves the text unselectable.

I'm fine with having -moz-user-select available for page content as long as the user can disable it (preferably via userContent.css), but the current behavior - overriding "!important" rules in the user stylesheet - is not acceptable and breaks the W3C standards.

Btw., how do screen readers handle non-selectable text?

Comment 8

[Uwe Schröder]

Hm. For some reason https://developer.mozilla.org/EN/CSS/-moz-user-select and https://developer.mozilla.org/DE/CSS/-moz-user-select contradict each other regarding the values -moz-user-select may take. While the German page says that possible values are "none", "normal", and "inherit", the English page lists "none", "text", and "-moz-none".

Using { -moz-user-select: text !important; } (instead of "normal" as in Comment #7) in userContent.css seems to work. So users *can* override the document style, and this is more likely a documentation bug.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The values of -moz-user-select are:  "auto" (the initial value, but only since bug 432888, before which the initial value actually couldn't be specified), "none", "text", "element", "elements", "all", "toggle", "tri-state", "-moz-all", and "-moz-none".

Comment 10

[Emil Ivanov]

(In reply to comment #7)

> I'm fine with having -moz-user-select available for page content as long as the
> user can disable it (preferably via userContent.css)

Using prefs to disable -moz-user-selection:none is too "in depth" and destroys the whole idea behind this property, it will be disabled for everything and not only for desired places.

I think that overriding -moz-user-select:none with some kind of a keyboard key like shift or ctrl and then select with mouse is better than disabling this functionality at all, which could be very well used for clickable elements and navigation.

Comment 11

[Mats Palmgren (inactive)]

I also disagree, for the same reason as bsmedberg.  Also, it's trivial
for authors to prevent selecting content using JS.  I've seen a few
versions of that in the wild and they can be even more annoying than
-moz-user-select is.

Fwiw, "View->Page Style->No Style" is already available to avoid any
restrictions made by -moz-user-select.

Preventing selection appears to be widely available in other UAs too:
(-webkit-user-select, -o-user-select, UNSELECTABLE attribute in IE)

Comment 12

[Daniel Kabs, reporting bugs since 2002]

I don't consider "View->Page Style->No Style" as a viable solution as it renders modern web pages beyond recognition.

Not being able to select parts of a page is very annoying and renders some of Firefox' function useles. E.g., without being able to select page elements, the user can not apply "View Selection Source" on them.

I voted for this bug because I want users to be able to override "-moz-user-select: none" (and frankly, any other crafty method that prevents users from selecting page content - but that's off topic here). The property "-moz-user-select:" can be understood as a user right restriction. I don't know why Firefox supports a restriction like that without providing a way to override it at the same time, especially as this restriction is not in the official W3C specs. 

Why not add a configuration option (in about:config) to override "(-moz-)user-select" property?

Comment 13

[Jonathan Watt [:jwatt]]

This has valid use cases, but I've noticed it being used in user hostile ways several times over the last two or three months. Latest example:

http://www.nia-uk.org/consumer/nia-members/online-directory/find/?postcode=SE1%200HS

This gives a list of companies, but the website has decided to make it impossible to select the company names, addresses, telephone numbers, email addresses and website URLs...exactly the pieces of info you'd want to copy and paste...

Comment 14

[Mats Palmgren (inactive)]

user-select:none is part of the web-platform and we can't remove it
for web-compat reasons.  Also, it has good use cases too (as noted above).

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Mats Palmgren (inactive) from comment #14)

user-select:none is part of the web-platform and we can't remove it
for web-compat reasons.

This is true to a certain extent, though the webcompat situation is complex:
(1) Safari seems to not support the unprefixed property at all; so a website setting user-select:none will get arguably-user-annoying behavior in Firefox vs. regular behavior in Safari.
(2) Chrome does support the unprefixed property, but they support it in a way that's at least substantially more nerfed than Firefox's implementation (and more nerfed than Safari's implementation of the webkit-prefixed property name). See bug 1773810 where the testcase (a textarea) is unselectable and minimally-editable in Firefox (e.g. uparrow/downarrow moves caret to start/end for no clear reason), and not-really-editable-at-all in Safari, but perfectly editable in Chrome.

So to the extent that there are webcompat constraints around unprefixed user-select, the constraints are in favor of us reducing its severity or even ignoring it.

We should probably revisit our decision to WONTFIX this. (Perhaps the stated summary "Do not expose -moz-user-select/-webkit-user-select to content" is too big of a hammer, but we might want to make some improvements in the interests of compat & user benefit.)

Comment 16

[Daniel Holbert [:dholbert]]

(CC'ing some interested folks, and clearing now-404 URL from comment 0)

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Well, yeah, I think the bug as described by the title is wontfix though. Specific compat issues are probably best addressed in separate bugs.

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)

Well, yeah, I think the bug as described by the title is wontfix though. Specific compat issues are probably best addressed in separate bugs.

That's fair. After a bit more digging, I filed bug 1774697 with a specific compat issue that seems valid & fixable.