Bug 173409 - Selection direction is lost after applying a style change
Summary: Selection direction is lost after applying a style change
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2017-06-15 04:54 PDT by Javier Fernandez
Modified: 2017-06-16 17:27 PDT (History)
5 users (show)

See Also:

Test case to reproduce the issue (827 bytes, text/html)
2017-06-16 00:47 PDT, Javier Fernandez
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Javier Fernandez 2017-06-15 04:54:09 PDT
What steps will reproduce the problem?
(1) Load the attached test case

What is the expected result?

'Anchor' offset is bigger than 'focus' offset, respecting the initial selection direction.

What happens instead?

'Anchor' offset is smaller than 'focus' offset.
Comment 1 Javier Fernandez 2017-06-15 04:54:18 PDT
This issue is not reproducible on Firefox or Edge/IE because these browsers are reseting the selection boundaries (at least the values returned by focus/anchor offsets) after applying the style change.

We don't do that, which I guess it's fine. However, I don't see any reason why we should forget about the previous selection direction. 

The attached case applies a new style to a portion of the text, which cause the DOM tree to change so the new styled text has it's own now. Hence, the selection  boundaries are adapted to the new DOM Tree. However, as I said, there is no reason why they should not respect the initial direction.
Comment 2 Darin Adler 2017-06-15 10:04:10 PDT
I don’t see an attached test case yet.
Comment 3 Javier Fernandez 2017-06-16 00:47:22 PDT
Created attachment 313059 [details]
Test case to reproduce the issue
Comment 4 Javier Fernandez 2017-06-16 00:48:30 PDT
BTW, Blink has decided to WONTFIX this issue. See https://crbug.com/733603 for details.
Comment 5 Javier Fernandez 2017-06-16 00:50:28 PDT
This are the results I've got using different browsers:

- Chrome: BEFORE: 10,5 AFTER: 5,10
- IE: BEFORE 10,5 AFTER 5,5
- Firefox: BEFORE 10,5 AFTER 5,5
- Safari: BEFORE 10,5, AFTER 5,10
Comment 6 Javier Fernandez 2017-06-16 01:06:52 PDT
It's worth mentioning that if the selected text is the whole text, so we don't have to split a new styled text node, these are the results I get:

- Chrome: BEFORE: 20,0 AFTER: 0,20
- IE: BEFORE 20,0 AFTER 20,0
- Firefox: BEFORE 20,0 AFTER 0,20
- Safari: BEFORE 20,0, AFTER 0,20
Comment 7 Ryosuke Niwa 2017-06-16 16:54:24 PDT
I can't reproduce this at all. When I open the test case in Safari 10.1 or STP32, I see:

anchorOffset = 10
focusOffset = 5
anchorOffset = 5
focusOffset = 0

Also, looking at offsets like this is red-herring since anchorNode/focusNode may have changed. Just offset 0 of one node may appear before offset 5 of another node for example.
Comment 8 Ryosuke Niwa 2017-06-16 16:55:44 PDT
Note that the current behavior of Safari is expected. We should not be collapsing selection upon changing the font color.
Comment 9 Javier Fernandez 2017-06-16 17:27:55 PDT
Yes, (In reply to Ryosuke Niwa from comment #8)
> Note that the current behavior of Safari is expected. We should not be
> collapsing selection upon changing the font color.

Yes, I made a mistake interpreting the result and the expected behavior. Safari's current behavior is correct for this case.