Bug 173409 – Selection direction is lost after applying a style change

• Component: HTML Editing
• Status: RESOLVED INVALID

[Javier Fernandez]

What steps will reproduce the problem?
(1) Load the attached test case
(2)
(3)

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.

[Javier Fernandez]

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.

[Darin Adler]

I don’t see an attached test case yet.

[Javier Fernandez]

Created attachment 313059 [details]
Test case to reproduce the issue

[Javier Fernandez]

BTW, Blink has decided to WONTFIX this issue. See https://crbug.com/733603 for details.

[Javier Fernandez]

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

[Javier Fernandez]

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

[Ryosuke Niwa]

I can't reproduce this at all. When I open the test case in Safari 10.1 or STP32, I see:

Before:
anchorOffset = 10
focusOffset = 5
After:
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.

[Ryosuke Niwa]

Note that the current behavior of Safari is expected. We should not be collapsing selection upon changing the font color.

[Javier Fernandez]

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.