Bug 82692 – -webkit-user-select: none makes text fields not editable

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Forms

[Ryosuke Niwa]

You can't edit text inside the input element in the following example:

<style type="text/css">
.filter *{
-webkit-user-select: none;
-khtml-user-select: none;
-moz-user-select: none;
-o-user-select: none;
user-select: none;
}
</style>
<div class="filter">
<input type="text" placeholder="foobar" />
</div>

We should probably be limiting the effect of -webkit-user-select at shadow DOM boundary.

[Ryosuke Niwa]

http://crbug.com/105876

[Rakesh]

Created attachment 146279 [details]
patch 1

Modified to check the user select none condition on shadow root.

[WebKit Review Bot]

Comment on attachment 146279 [details]
patch 1

Attachment 146279 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12910386

New failing tests:
editing/selection/select-all-user-select-none.html
fast/forms/input-select-webkit-user-select-none.html
editing/selection/5333725.html
fast/events/mouse-double-triple-click-should-not-select-next-node-for-user-select-none.html
editing/selection/5779984-1.html

[WebKit Review Bot]

Created attachment 146356 [details]
Archive of layout-test-results from ec2-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Ryosuke Niwa]

Comment on attachment 146279 [details]
patch 1

View in context: https://bugs.webkit.org/attachment.cgi?id=146279&action=review

> Source/WebCore/dom/Position.cpp:852
> -    return node && node->renderer() && node->renderer()->style()->userSelect() == SELECT_NONE;
> +    return node && node->renderer() && node->renderer()->style()->userSelect() == SELECT_NONE && node->isShadowRoot();

This is not the right fix. We need to update the style resolution code instead.
Otherwise, -webkit-user-select: none would never work inside shadow DOM.

[Rakesh]

(In reply to comment #5)
> This is not the right fix. We need to update the style resolution code instead.
> Otherwise, -webkit-user-select: none would never work inside shadow DOM.

You are right, will check in style resolution code for better fix.

[Ryosuke Niwa]

See the bug 88514. We're implementing the right solution for -webkit-user-modify there.

[Dean Johnson]

Still running into this on trunk WebKit -- was there any resolution on the correct behavior?

[Ben Frain]

Here is a reduction of this issue:

http://codepen.io/benfrain/pen/PZBOjJ

Attempt to select the text and nothing is selected - correct
Type in the input and nothing appears - incorrect

This works fine in Chrome & Firefox as per specifications: http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-select

[Ben Frain]

Note for authors looking for a workaround, you can do this:

* {
	user-select: none;
}

input[type] {
	user-select: text;
}

in your CSS and inputs won't get the lanky user-select experience in Safari/iOS

Just wanted to mention that I ran into this bug recently—we had accidentally applied user-select: none to a couple of our search fields, but since it worked fine on Chrome & Firefox we didn't notice for a long time that search was broken on Safari. We fixed it by removing the user-select: none style, but definitely a web-compat issue waiting to happen!

[Carlos Alberto Lopez Perez]

Created attachment 393234 [details]
Patch

[Darin Adler]

Comment on attachment 393234 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=393234&action=review

Bug title makes the patch sound like this affects only text fields. Do we have extensive enough tests to see all the cases this affects?

> Source/WebCore/dom/Position.cpp:930
>  bool Position::nodeIsUserSelectNone(Node* node)
>  {
> -    return node && node->renderer() && node->renderer()->style().userSelect() == UserSelect::None;
> +    return node && node->renderer() && node->renderer()->style().userSelect() == UserSelect::None && node->renderer()->style().userModify() == UserModify::ReadOnly;
>  }

Before this patch, the function name here literally described its function. How the function does a "derived operation" that checks more than just "user select none", so I suggest renaming it. Maybe something like "unselectable" or "selectable" since that’s the term you coined inside RenderElement.cpp, or maybe "editable".

Also, the expression is now long enough that we might want to switch to the vertical && style we use for long expressions.

    return node && node->renderer()
        && node->renderer()-> ...
        && ...;

Finally, I suggest sharing code between this and the code inside RenderElement. Perhaps we should make this a public function member on RenderElement? Or maybe it should stay somewhere in editing code. Maybe it’s OK to leave it a member of Position, but we should offer a version that takes a const RenderStyle& alongside a different version that takes a Node*, which calls the RenderStyle one.

We should *not* change this function’s meaning without changing its name.

[Ryosuke Niwa]

Comment on attachment 393234 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=393234&action=review

> Source/WebCore/dom/Position.cpp:929
> +    return node && node->renderer() && node->renderer()->style().userSelect() == UserSelect::None && node->renderer()->style().userModify() == UserModify::ReadOnly;

This is clearly not right. We have an important client for -webkit-user-select: none that uses it in contenteditable.

[Ryosuke Niwa]

Comment on attachment 393234 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=393234&action=review

> Source/WebCore/ChangeLog:8
> +        This patch makes CSS property -webkit-user-select:none not to affect editability as FireFox and Chromium.

This description is inaccurate. What you're doing is disabling -webkit-user-select: none inside any editable region. This is not okay.

[Carlos Alberto Lopez Perez]

(In reply to Darin Adler from comment #13)
> Comment on attachment 393234 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=393234&action=review
> 
> Bug title makes the patch sound like this affects only text fields. Do we
> have extensive enough tests to see all the cases this affects?
> 

I hope so. I ran all the layout tests and did a bunch of manual tests.
Do you have any suggestions for testing this other than running all the WebKit layout tests?

> > Source/WebCore/dom/Position.cpp:930
> >  bool Position::nodeIsUserSelectNone(Node* node)
> >  {
> > -    return node && node->renderer() && node->renderer()->style().userSelect() == UserSelect::None;
> > +    return node && node->renderer() && node->renderer()->style().userSelect() == UserSelect::None && node->renderer()->style().userModify() == UserModify::ReadOnly;
> >  }
> 
> Before this patch, the function name here literally described its function.
> How the function does a "derived operation" that checks more than just "user
> select none", so I suggest renaming it. Maybe something like "unselectable"
> or "selectable" since that’s the term you coined inside RenderElement.cpp,
> or maybe "editable".
> 
> Also, the expression is now long enough that we might want to switch to the
> vertical && style we use for long expressions.
> 
>     return node && node->renderer()
>         && node->renderer()-> ...
>         && ...;
> 
> Finally, I suggest sharing code between this and the code inside
> RenderElement. Perhaps we should make this a public function member on
> RenderElement? Or maybe it should stay somewhere in editing code. Maybe it’s
> OK to leave it a member of Position, but we should offer a version that
> takes a const RenderStyle& alongside a different version that takes a Node*,
> which calls the RenderStyle one.
> 
> We should *not* change this function’s meaning without changing its name.

Here I backported a patch from Chromium that fixed this bug pretty much as this patch, I simply renamed the function shouldUseSelectionColor() to isUnselectable() and inverted the order (as it looked more readable to me)  See: https://chromium.googlesource.com/chromium/src/+/f66b7d356cf75be230690332b1ac34951e8b018c%5E%21/


I will try to take your suggestions (and Ryosuke ones) into account for a next version of the patch. Thanks

[Carlos Alberto Lopez Perez]

(In reply to Ryosuke Niwa from comment #15)
> Comment on attachment 393234 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=393234&action=review
> 
> > Source/WebCore/ChangeLog:8
> > +        This patch makes CSS property -webkit-user-select:none not to affect editability as FireFox and Chromium.
> 
> This description is inaccurate. What you're doing is disabling
> -webkit-user-select: none inside any editable region. This is not okay.

I agree that the description can be improved, but ..

do you mean its not ok to disable -webkit-user-select: none inside any editable region ? why?

I have created this simple test:

https://people.igalia.com/clopez/wkbug/82692/test-select-none-input-div-contenteditable.html


As far as I can see, this happens:

 * firefox allows to edit on any input element (test1) or any editable element (test3), but it doesn't allow to select the text with the mouse cursor.
 * chrome allows both to edit and to select the text with the mouse cursor on any input element (test1) and editable element (test3)
 * webkit doesn't allow to edit, neither to select the text (test1 and test3).


What should be the desired behaviour? My goal was to align this behaviour with what Chrome does to reduce the risk of web-compat before unprefixing this property in bug 208677

[Ryosuke Niwa]

(In reply to Carlos Alberto Lopez Perez from comment #17)
> (In reply to Ryosuke Niwa from comment #15)
> > Comment on attachment 393234 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=393234&action=review
> > 
> > > Source/WebCore/ChangeLog:8
> > > +        This patch makes CSS property -webkit-user-select:none not to affect editability as FireFox and Chromium.
> > 
> > This description is inaccurate. What you're doing is disabling
> > -webkit-user-select: none inside any editable region. This is not okay.
> 
> I agree that the description can be improved, but ..
> 
> do you mean its not ok to disable -webkit-user-select: none inside any
> editable region ? why?

Definitely not.

> I have created this simple test:
> 
> https://people.igalia.com/clopez/wkbug/82692/test-select-none-input-div-
> contenteditable.html
> 
> 
> As far as I can see, this happens:
> 
>  * firefox allows to edit on any input element (test1) or any editable
> element (test3), but it doesn't allow to select the text with the mouse
> cursor.
>  * chrome allows both to edit and to select the text with the mouse cursor
> on any input element (test1) and editable element (test3)
>  * webkit doesn't allow to edit, neither to select the text (test1 and
> test3).

That's the expected behavior. We don't want to allow editing of with -webkit-user-select: none. Content outside of what's being marked as -webkit-user-select: none should be editable, but not the content marked as -webkit-user-select: none.

> What should be the desired behaviour? My goal was to align this behaviour
> with what Chrome does to reduce the risk of web-compat before unprefixing
> this property in bug 208677

I don't think that's something we want to do.

(In reply to Carlos Alberto Lopez Perez from comment #17)
>  * firefox allows to edit on any input element (test1) or any editable
> element (test3), but it doesn't allow to select the text with the mouse
> cursor.

Just as a clarification, in my browser (Firefox 73 on macOS), I am able to select text and edit freely inside the input element. Screen recording: https://www.dropbox.com/s/nomf5jkdybx42iq/user%20select%20none.mp4?dl=0

I have no real opinion on contenteditable behavior, it definitely seems like more of an edge case.

[Carlos Alberto Lopez Perez]

(In reply to Ryosuke Niwa from comment #18)
> > What should be the desired behaviour? My goal was to align this behaviour
> > with what Chrome does to reduce the risk of web-compat before unprefixing
> > this property in bug 208677
> 
> I don't think that's something we want to do.

Ok, so if I understood you right, we only want to allow editing text inside <input> elements. That's right?

And other than editing, what about selecting text with the mouse inside an input element that has -webkit-user-select:none? Do we want to allow that?

[Ryosuke Niwa]

(In reply to Carlos Alberto Lopez Perez from comment #20)
> (In reply to Ryosuke Niwa from comment #18)
> > > What should be the desired behaviour? My goal was to align this behaviour
> > > with what Chrome does to reduce the risk of web-compat before unprefixing
> > > this property in bug 208677
> > 
> > I don't think that's something we want to do.
> 
> Ok, so if I understood you right, we only want to allow editing text inside
> <input> elements. That's right?

Right.

> And other than editing, what about selecting text with the mouse inside an
> input element that has -webkit-user-select:none? Do we want to allow that?

I guess we can match other browsers there. I don't think -webkit-user-select: none on input element is a scenario we deeply care about although any backwards incompatible change is risky so such a code change should be very carefully studied.

[Carlos Alberto Lopez Perez]

(In reply to Ryosuke Niwa from comment #21)
> (In reply to Carlos Alberto Lopez Perez from comment #20)
> > (In reply to Ryosuke Niwa from comment #18)
> > > > What should be the desired behaviour? My goal was to align this behaviour
> > > > with what Chrome does to reduce the risk of web-compat before unprefixing
> > > > this property in bug 208677
> > > 
> > > I don't think that's something we want to do.
> > 
> > Ok, so if I understood you right, we only want to allow editing text inside
> > <input> elements. That's right?
> 
> Right.
> 

What about <textarea> ? Should that be editable if it has -webkit-user-select:no ?

[Ryosuke Niwa]

(In reply to Carlos Alberto Lopez Perez from comment #22)
> (In reply to Ryosuke Niwa from comment #21)
> > (In reply to Carlos Alberto Lopez Perez from comment #20)
> > > (In reply to Ryosuke Niwa from comment #18)
> > > > > What should be the desired behaviour? My goal was to align this behaviour
> > > > > with what Chrome does to reduce the risk of web-compat before unprefixing
> > > > > this property in bug 208677
> > > > 
> > > > I don't think that's something we want to do.
> > > 
> > > Ok, so if I understood you right, we only want to allow editing text inside
> > > <input> elements. That's right?
> > 
> > Right.
> > 
> 
> What about <textarea> ? Should that be editable if it has
> -webkit-user-select:no ?

Same as input. We can probably match what other browsers are doing.

[Radar WebKit Bug Importer]

<rdar://problem/89481736>

[Tim Nguyen (:ntim)]

Going to fix this in bug 118009.

*** This bug has been marked as a duplicate of bug 118009 ***