Bug 82692

Summary: -webkit-user-select: none makes text fields not editable
Product: WebKit Reporter: Ryosuke Niwa <rniwa>
Component: FormsAssignee: Rakesh <rakeshchaitan>
Status: NEW ---    
Severity: Normal CC: adele, contact, dbates, dglazkov, enrica, evan, morrita, rakeshchaitan, shinyak, tellowkrinkle, tkent, webkit.review.bot, wenson_hsieh
Priority: P2 Keywords: HasReduction
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 88514    
Bug Blocks:    
Attachments:
Description Flags
patch 1
rniwa: review-, webkit.review.bot: commit-queue-
Archive of layout-test-results from ec2-cr-linux-03 none

Description Ryosuke Niwa 2012-03-29 22:55:42 PDT
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.
Comment 1 Ryosuke Niwa 2012-03-29 22:55:58 PDT
http://crbug.com/105876
Comment 2 Rakesh 2012-06-07 06:52:04 PDT
Created attachment 146279 [details]
patch 1

Modified to check the user select none condition on shadow root.
Comment 3 WebKit Review Bot 2012-06-07 12:11:28 PDT
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
Comment 4 WebKit Review Bot 2012-06-07 12:11:32 PDT
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
Comment 5 Ryosuke Niwa 2012-06-07 13:53:55 PDT
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.
Comment 6 Rakesh 2012-06-08 07:51:22 PDT
(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.
Comment 7 Ryosuke Niwa 2012-06-08 09:31:28 PDT
See the bug 88514. We're implementing the right solution for -webkit-user-modify there.
Comment 8 Dean Johnson 2015-11-17 16:06:29 PST
Still running into this on trunk WebKit -- was there any resolution on the correct behavior?
Comment 9 Ben Frain 2016-02-02 02:47:04 PST
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
Comment 10 Ben Frain 2016-02-02 02:58:28 PST
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
Comment 11 evan 2019-11-25 07:34:17 PST
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!