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.
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.
I don’t see an attached test case yet.
Created attachment 313059 [details] Test case to reproduce the issue
BTW, Blink has decided to WONTFIX this issue. See https://crbug.com/733603 for details.
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
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
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.
Note that the current behavior of Safari is expected. We should not be collapsing selection upon changing the font color.
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.