Bug 140388 - Range is incorrectly normalized after adding into selection for u HTML element.
Summary: Range is incorrectly normalized after adding into selection for u HTML element.
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-01-13 04:23 PST by a.delura
Modified: 2023-03-28 15:52 PDT (History)
9 users (show)

See Also:


Attachments
Reproduction example (597 bytes, text/html)
2015-01-13 04:23 PST, a.delura
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description a.delura 2015-01-13 04:23:34 PST
Created attachment 244507 [details]
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.
Comment 1 a.delura 2015-01-13 04:27:39 PST
Reproduced on latest nightly r178314
Comment 2 Piotrek Koszuliński (Reinmar) 2015-01-13 05:49:39 PST
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.
Comment 3 Alexey Proskuryakov 2015-01-13 20:38:27 PST
Can you figure out when this started? That would significantly increase the chances of this being fixed.
Comment 4 Ahmad Saleem 2022-08-08 17:42:29 PDT
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!
Comment 5 Radar WebKit Bug Importer 2022-08-10 11:04:17 PDT
<rdar://problem/98460579>
Comment 6 Ahmad Saleem 2023-03-27 15:38:02 PDT
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.
Comment 7 Ryosuke Niwa 2023-03-28 15:52:49 PDT
Yeah, this seems to be working now.