140388 2015-01-13 04:23:34 -0800 Range is incorrectly normalized after adding into selection for u HTML element. 2023-03-28 15:52:49 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED CONFIGURATION CHANGED InRadar P2 Normal --- 1 a.delura webkit-unassigned a.delura ahmad.saleem792 ap bfulgham enrica gsnedders pkoszulinski rniwa webkit-bug-importer oldest_to_newest 1060801 0 244507 a.delura 2015-01-13 04:23:34 -0800 Created attachment 244507 Reproduction example Creating range for text node in u HTML element and adding it to selection cause incorrectly range normalization to it's parent. See attached example for more details. Please note, that this bug occur not only for u element but for inline elements in general i.e. i, em, b. This bug does not occur for block elements like p or div. This behaviour impact http://dev.ckeditor.com/ticket/12690 in CKEditor. 1060802 1 a.delura 2015-01-13 04:27:39 -0800 Reproduced on latest nightly r178314 1060812 2 pkoszulinski 2015-01-13 05:49:39 -0800 Rephrasing the bug report: Selection anchored in a text node inside an inline element (e.g. <u>) is incorrectly normalised by Webkit - it is moved to a text node outside that <u> element. While Webkit normalising an element-anchored selection to a closest text node is a fact (a sad one :)), I would expect that it does not affect selections anchored in text nodes. This looks like some pretty new regression, because I've never seen Webkit doing this. Of course, none other browser behave this way, but that's due to the fact that none other browser normalise selection. 1061054 3 ap 2015-01-13 20:38:27 -0800 Can you figure out when this started? That would significantly increase the chances of this being fixed. 1889868 4 ahmad.saleem792 2022-08-08 17:42:29 -0700 I am able to reproduce this bug in Safari 15.6 on macOS 12.5 using attached test case and it returns "f" in the console while in other browsers (Chrome Canary 106 and Firefox Nightly 105), it returns "o" in the console. Thanks! 1890356 5 webkit-bug-importer 2022-08-10 11:04:17 -0700 <rdar://problem/98460579> 1944402 6 ahmad.saleem792 2023-03-27 15:38:02 -0700 Safari 16.4 shows 'f' (not expected) but Safari Technology Preview 166 show 'o' in Console. Used "Private Window" to reproduce this. Can we mark this as "RESOLVED CONFIGURATION CHANGED", since it seems to be fixed in STP166. 1944780 7 rniwa 2023-03-28 15:52:49 -0700 Yeah, this seems to be working now. 244507 2015-01-13 04:23:34 -0800 2015-01-13 04:23:34 -0800 Reproduction example webkit-bug.html text/html 597 a.delura PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KICA8bWV0YSBjaGFyc2V0PSJ1dGYtOCI+CiAg PHRpdGxlPldlYmtpdCBidWc8L3RpdGxlPgo8L2hlYWQ+Cjxib2R5PmY8dT5vPC91Pgo8c2NyaXB0 IGlkPSJqc2Jpbi1qYXZhc2NyaXB0Ij4NCi8vIFNlbGVjdGluZyB0ZXh0IG5vZGUgaW4gdSBlbGVt ZW50Lg0KdmFyIG8gPSBkb2N1bWVudC5xdWVyeVNlbGVjdG9yKCd1JykuY2hpbGROb2Rlc1swXTsN Cg0KLy8gQ3JlYXRpbmcgcmFuZ2UganVzdCBiZWZvcmUgIm8iIGNoYXJhY3RlciBpbiB1IGVsZW1l bnQuDQp2YXIgcmFuZ2UgPSBkb2N1bWVudC5jcmVhdGVSYW5nZSgpOw0KcmFuZ2Uuc2V0U3RhcnQo bywgMCk7DQpyYW5nZS5zZXRFbmQobywgMCk7DQoNCndpbmRvdy5nZXRTZWxlY3Rpb24oKS5hZGRS YW5nZShyYW5nZSk7DQoNCi8vIFJhbmdlIGlzIGluY29ycmVjdGx5IG5vcm1hbGl6ZWQgdG8gImYi IHRleHQgbm9kZSwgYnV0IHNob3VsZCBiZSBrZXB0IGluICJvIg0KY29uc29sZS5sb2cod2luZG93 LmdldFNlbGVjdGlvbigpLmdldFJhbmdlQXQoMCkuc3RhcnRDb250YWluZXIudGV4dENvbnRlbnQp Owo8L3NjcmlwdD4KPC9ib2R5Pgo8L2h0bWw+