Last Comment Bug 816298 - Change "-moz-user-select:none" to behave like WebKit, IE, and Opera (and "-moz-user-select:-moz-none")
: Change "-moz-user-select:none" to behave like WebKit, IE, and Opera (and "-mo...
: compat, dev-doc-complete
Product: Core
Classification: Components
Component: DOM: CSS Object Model (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla21
Assigned To: Chris Peterson [:cpeterson]
: Andrew Overholt [:overholt]
Depends on: 739396 832514
Blocks: 799029 814274
  Show dependency treegraph
Reported: 2012-11-28 15:03 PST by Chris Peterson [:cpeterson]
Modified: 2014-09-10 18:03 PDT (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

part-1-change-moz-user-select-none.patch (10.72 KB, patch)
2013-01-17 19:26 PST, Chris Peterson [:cpeterson]
ehsan: review+
Details | Diff | Splinter Review
part-2-remove-moz-user-select-moz-none.patch (3.45 KB, patch)
2013-01-17 19:28 PST, Chris Peterson [:cpeterson]
ehsan: review+
enndeakin: review+
Details | Diff | Splinter Review

Description Chris Peterson [:cpeterson] 2012-11-28 15:03:56 PST
-moz-user-select [1] is not part of any W3C CSS spec, but some major websites are (mis)using it on their mobile websites: bug 814274, bug 799029.

Our -moz-user-select:none behaves as proposed in the css3-userint TR [2] but WebKit, IE, and Opera's "-XXX-user-select:none" behave like "-moz-user-select:-moz-none". Unfortunately, this causes problems for Twitter and Facebook on B2G and Android. Plus, Twitter's popular "Bootstrap" website template uses "-moz-user-select:none", thus spreading the bug to other websites.

I think this change in behavior should be pretty safe. The use case that would break is where an element has -moz-user-select:none, a sub-element has -moz-user-select:whatever, *and* the developer expects that the sub-element's -moz-user-select:whatever will be *ignored* (because of the parent element's "none"). And AFAIU, the breakage is simply that the sub-element's content might become selectable.

Firefox's chrome and some addons use "-moz-user-select:none", but it is hard to know whether they need or intended to use Firefox's unique behavior. If we want to be conservative, we could define a new -moz-user-select value (something like a "-moz-disabled"?) to preserve our current behavior for internal use.

* Firefox code uses any "-moz-user-select" 101 times in 44 files
* Firefox code uses "-moz-user-select: ?none" 59 times in 28 files
* Firefox code uses "-moz-user-select: ?-moz-none" 9 times in 5 files

Here are some numbers from AMO MXR (

9095 extensions hosted on AMO
~350 extensions use any "-moz-user-select"
~200 extensions use "-moz-user-select: ?none"
~100 extensions use "-moz-user-select: ?-moz-none"
 ~90 extensions use any "-webkit-user-select"
 ~80 extensions use "-webkit-user-select: ?none"
   1 extension uses any "-webkit-user-select: ?-moz-none"!! :) 

Comment 1 Chris Peterson [:cpeterson] 2013-01-17 19:26:46 PST
Created attachment 703724 [details] [diff] [review]

Part 1: Allow child elements to override -moz-user-select:none.

This patch allows -moz-user-select:none to be overriden by child elements with -moz-user-select:text. This matches the current behavior of -moz-none and WebKit, IE, and Opera's `none`.

Two important differences, that remain unchanged, between -moz-user-select:none (and -moz-none) and -webkit-user-select:none is the highlighting and copying of text. Would you like me to open another bug report for these differences?

* Gecko: CMD+A (or dragging a selection) will highlight all text, INCLUDING the `none` text.
* WebKit: CMD+A (or dragging a selection) will highlight the text surrounding a `none` span, but NOT the `none` text.

* Gecko: CMD+C will copy the text surrounding a `none` span, but NOT the `none` text. 
* WebKit: CMD+C will copy all text, INCLUDING the `none` text.

I feel that highlighting text we are not going to copy is misleading.

Someone filed a WebKit bug about WebKit copying `none` text, but the bug report has no resolution:
Comment 2 Chris Peterson [:cpeterson] 2013-01-17 19:28:12 PST
Created attachment 703725 [details] [diff] [review]

Part 2: Replace Gecko's references to -moz-user-select:-moz-none with -moz-user-select:none, since they should be equivalent now.
Comment 3 Chris Peterson [:cpeterson] 2013-01-17 19:28:54 PST
If this change is accepted, the MDN docs will need to be updated:
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2013-01-17 19:49:13 PST
Comment on attachment 703724 [details] [diff] [review]

Punting to someone who might know about this stuff...
Comment 5 Chris Peterson [:cpeterson] 2013-01-18 09:23:37 PST
Comment on attachment 703725 [details] [diff] [review]

Comment 6 :Ehsan Akhgari 2013-01-18 13:30:32 PST
Chris, sorry but I don't have enough time to review this today.  I will do that hopefully early next week.
Comment 7 Chris Peterson [:cpeterson] 2013-01-18 14:32:13 PST
btw, the unexpected highlighting of "-moz-user-select:none" text that we are not going to copy is a regression in Firefox 11. I filed bug 832514 to track that bug.
Comment 8 :Ehsan Akhgari 2013-01-21 08:21:16 PST
I wish there was a way for us to know how many websites depend on -moz-none, so that we could potentially just remove it and only have the `none' semantics.  Oh, and did I mention I hate -vendor-user-select?  :(
Comment 9 :Ehsan Akhgari 2013-01-21 08:27:00 PST
Comment on attachment 703724 [details] [diff] [review]

Review of attachment 703724 [details] [diff] [review]:

r=me, but we should watch very closely for regressions...
Comment 12 Chris Peterson [:cpeterson] 2013-01-28 11:40:10 PST
I updated MDN's user-select page to say that, starting with Firefox 21, -moz-user-select:none will allow selection to be re-enabled on sub-elements using -moz-user-select:text.

I will leave the Facebook and Twitter evangelism bugs open because current Firefox versions (including B2G) have the old -moz-user-select:none behavior. :(

Note You need to log in before you can comment on or make changes to this bug.