Closed Bug 477152 Opened 15 years ago Closed 2 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: faaborg, Unassigned)

References

Details

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.
disabling http://www.sheahomes.com/css/dhtml-horiz.css seems to enable selection...
sorry, wrong bit of css but it's in there somewhere
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).
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)
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.
Summary: Can't select text on this page → Do not expose -moz-user-select to content
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → style-system
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
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?
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.
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".
(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.
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)
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?
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...
Summary: Do not expose -moz-user-select to content → Do not expose -moz-user-select/-webkit-user-select to content (user hostile)
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).
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX

(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.)

Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

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

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

(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.

Status: REOPENED → RESOLVED
Closed: 6 years ago2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.