Chrome doesn't style correctly when characters in two different spans are being deleted
Reported by
grigoriy...@gmail.com,
Oct 5 2016
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.14939 Example URL: https://jsfiddle.net/whbk8npa/4/ Steps to reproduce the problem: 1. Navigate to https://jsfiddle.net/whbk8npa/4/ 2. Place a caret to the right of character 'a' 3. Keep pressing delete button until no characters to the right of 'a' are left. 4. Type new character, 'z' for example. What is the expected behavior? 'z' is formatted in red font What went wrong? 'z' is formatted in blue font Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 52.0.2743.116 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 There is a W3C discussion going on this: Thanks, Ojan. Agree with rationale behind links. I filed a bug on Chrome here since it looks like there is a bug in Windows. Sent from Outlook ________________________________________ From: Ojan Vafai <ojan@google.com> Sent: Friday, September 30, 2016 4:55:27 AM To: Grisha Lyukshin; public-editing-tf Cc: Anupam Snigdha Subject: Re: style preserving when forward deleting characters in content editable div I'm seeing Chrome and Edge do the same thing in your second test case (i.e. the z is red). Maybe I'm mistesting? It could be we do something different on Windows, but that would be a bug. My mental model of the Chrome (and Safari) behavior is that we always grab the style of the content to the left of the caret, except for links. Links are special because they're not just styling. Users are most annoyed by being unable to escape them and often rich text widgets don't give an easy way of truncating anchors they way they do styling. Although, I'll admit that our current behavior of inserting unstyled black text is a bit unexpected, it's not a thing I've ever heard complaints about. https://jsfiddle.net/whbk8npa/2/ To be clear, we only treat links specially, not all anchor tags (i.e. if it has no href, it's the same as a span). The Firefox behavior has nothing to do with delete. It has to do with which direction your selection approached that point in the DOM from. You can repeat the same behavior with <span>a</span><span>b</span> and approaching the point between a and b from different directions. On Fri, Sep 30, 2016 at 1:48 AM Grisha Lyukshin <glyuk@microsoft.com> wrote: Hello Editing Task Force, I wanted to run the following scenario by you and hear your stance on it? Here is the use case code snippet: <body contenteditable="true"> <div><span style="color:red;">a</span></div> <div><span style="color:blue;">bc</span></div> </body> Jsfiddle: https://jsfiddle.net/whbk8npa/ this markup will be displayed to the user like a bc 1. Place a caret to the right of character 'a' 2. Hit delete (new line will be removed and user will see 'abc' 3. Hit delete again and user will see 'ac' 4. Type some character, 'z' for example. User will see different results, depending on the browser: Chrome Edge Firefox Safari azc azc azc Didn't test - someone who has Safari, please test *It seems that Chrome and Edge grab styles from the span that is to the left of 'a' and Firefox grabs the stylse from the span to the right of 'a'. Now, repeat the experiment but this time, delete everything to the right of 'a' so the end result would look like so 'a'. Results are again, quite different. Chrome Edge Firefox Safari az az az Didn't test - someone who has Safari, please test In this case, Chrome seems to grabs the style from the span to the right of 'a' if the last character in the span has been removed. Edge still grabs styles from the span that is to the left of 'a'. Firefox seems to do its own thing. What do you think the most sensible behavior here is? I believe, we should keep things simple - in accordance with how desktop and online editors do. Always grab styles from the left of 'a'. Thoughts? - Grisha Sent from Outlook
,
Oct 6 2016
Hi, the issue is in your first observation - When user deletes all characters to the right of 'a' and then inserts any character, 'z' for example, newly typed character is expected to have red font and not blue.
,
Oct 14 2016
Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 17 2016
Tested issue on windows 10 , linux Ubuntu 14.04 using chrome latest stable M54 - #54.0.2840.59 and issue is reproduced. Issue is seen from M30 # 30.0.1549.0 and hence it is a Non-regression issue. Note : In Mac , delete button functionality is different. Hence, not marking as mac specific issue. Thanks !
,
Oct 20 2016
,
Oct 21 2016
,
Oct 25 2016
,
Oct 4 2017
,
Oct 4
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 5
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by rbasuvula@chromium.org
, Oct 6 2016Labels: Needs-Feedback