Do not expose -moz-user-select/-webkit-user-select to content (user hostile)
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
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.
Comment 1•15 years ago
|
||
disabling http://www.sheahomes.com/css/dhtml-horiz.css seems to enable selection...
Comment 2•15 years ago
|
||
sorry, wrong bit of css but it's in there somewhere
Reporter | ||
Comment 3•15 years ago
|
||
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•15 years ago
|
||
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)
Reporter | ||
Comment 5•15 years ago
|
||
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.
Updated•15 years ago
|
Comment 6•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
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".
Comment 10•15 years ago
|
||
(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•14 years ago
|
||
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•11 years ago
|
||
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•6 years ago
|
||
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...
Updated•6 years ago
|
Comment 14•6 years ago
|
||
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).
Updated•6 years ago
|
Comment 15•2 years ago
|
||
(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•2 years ago
|
||
(CC'ing some interested folks, and clearing now-404 URL from comment 0)
Comment 17•2 years ago
|
||
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•2 years ago
|
||
(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.
Description
•