38703 2010-05-06 16:04:18 -0700 user-select none should not clear selection 2026-08-19 09:01:51 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) All All NEW HasReduction, InRadar P2 Normal --- 208677 1 arv webkit-unassigned ap arv caleb enrica franco_vieira gmak megan_gardner neil.ashford rniwa webkit-bug-importer wenson_hsieh oldest_to_newest 222032 0 55315 arv 2010-05-06 16:04:18 -0700 Created attachment 55315 Test If I have some selected text and then do a mousedown on an element that has user-select none the current selection should not be cleared. The code to fix this is in Node::canStartSelection. if (style->userDrag() == DRAG_ELEMENT && style->userSelect() == SELECT_NONE) should be changed to if (style->userDrag() == DRAG_ELEMENT || style->userSelect() == SELECT_NONE) The following two LayoutTests needs to be updated as well: editing/selection/5333725.html editing/selection/user-drag-element-and-user-select-none.html 269340 1 gmak 2010-08-25 10:48:18 -0700 Does this need #if ENABLE(DRAG_SUPPORT) flags as well? It will probably work fine without with the proposed change but all other uses of userDrag() have the define wrapped around it somewhere. 1726962 2 419682 neil.ashford 2021-02-08 23:41:15 -0800 Created attachment 419682 An extra HTML file with a similar (possibly the same) issue The same issue, but specifically where the first selection is in a content editable element, is affecting my product. I'm using Safari 14.0.2 on MacOS 11.1, so it looks like this bug (or some variant of it) is still happening. 1752272 3 caleb 2021-04-20 08:46:10 -0700 Based on the "Test" attachment, the original bug looks fixed: clicking on `-webkit-user-select: none` doesn't destroy text selection. But like Neil said, it _does_ destroy selection if the selection is in [contentEditable]. This makes it really difficult to support Safari if you have a WYSIWYG editor and have div-based controls that operate on the selection. You want the selection to stay the same while the user formats it. Oddly the native <button> passes the test cases in both attachments. 2239963 4 franco_vieira 2026-08-13 07:55:27 -0700 Currently, user-select is not implemented since we only support -webkit-user-select. This explains the undesired behavior in Neil's example. Strictly speaking, this does not reproduce: if the pointer is held steady, clicking an element with -webkit-user-select: none does not clear selection in the given example. However, minor pointer movements while clicking do cause the selection to be cleared, which is still very bad for the WYSIWYG editor use case, and a divergence from other major browsers, so keeping this open. 2241811 5 webkit-bug-importer 2026-08-19 09:01:51 -0700 <rdar://problem/185324533> 55315 2010-05-06 16:04:18 -0700 2010-05-06 16:04:18 -0700 Test user-select-none-should-not-clear-selection.html text/html 174 arv PCFET0NUWVBFIGh0bWw+Cgo8cD4xLiBTZWxlY3QgbWU8L3A+Cgo8cCBzdHlsZT0iLXdlYmtpdC11 c2VyLXNlbGVjdDogbm9uZTsgLW1vei11c2VyLXNlbGVjdDogbm9uZSI+Mi4gTW91c2UgZG93biBo ZXJlPC9wPgoKPHA+VGhlIHNlbGVjdGlvbiBzaG91bGQgbm90IGhhdmUgYmVlbiBjbGVhcmVkLjwv cD4K 419682 2021-02-08 23:41:15 -0800 2021-02-08 23:41:15 -0800 An extra HTML file with a similar (possibly the same) issue TINY-4222.html text/html 454 neil.ashford PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KPGhlYWQ+CiAgICA8bWV0YSBjaGFyc2V0 PSJVVEYtOCI+CiAgICA8dGl0bGU+U2FmYXJpIEJ1ZzwvdGl0bGU+CjwvaGVhZD4KPGJvZHk+Cjxo MT5TYWZhcmkgYnVnPC9oMT4KPGJsb2NrcXVvdGU+QSBidWcgaW4gc2FmYXJpJ3MgPGNvZGU+dXNl ci1zZWxlY3Q6IG5vbmU8L2NvZGU+IGhhbmRsaW5nPC9ibG9ja3F1b3RlPgo8bWFpbiBzdHlsZT0i ZGlzcGxheTogZmxleDsgZmxleC1kaXJlY3Rpb246IGNvbHVtbjsiPgogICAgPGRpdiBjb250ZW50 ZWRpdGFibGU9InRydWUiPk1ha2UgYSBzZWxlY3Rpb24gaW5zaWRlIG9mIHRoaXMgdGV4dDwvZGl2 PgogICAgPGRpdiBzdHlsZT0iYm9yZGVyOiAycHggc29saWQgYmxhY2s7IHVzZXItc2VsZWN0OiBu b25lOyI+QW5kIHRoZW4gY2xpY2sgaGVyZTwvZGl2Pgo8L21haW4+CjwvYm9keT4KPC9odG1sPg==