cannot delete contenteditable false inside contenteditable true
Reported by
dennis.c...@gmail.com,
May 17 2016
|
||||||
Issue descriptionExample URL: http://moxio.com/contenteditable.html Steps to reproduce the problem: 1. put caret at end of contenteditable div 2. press backspace to remove red block which is not contenteditable What is the expected behavior? I would expect the same behavior as the non-android chrome -> backspacing into a contenteditable=false element deletes the entire element. What went wrong? Instead something funky happens with part of the text being duplicated after the contenteditable=false. See attached testcase or webbased testcase. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 50.0.2661.89 Channel: stable OS Version: 5.1.1 Flash Version: We have tested multiple Android phones at our office (all running same version of Chrome) and they all display similar behavior. This is a simplified testcase, in the actual case the contenteditable=false element is inserted when we detect a mention (similar to google+/twitter).
,
May 17 2016
,
May 17 2016
,
May 28 2016
Hmm this might be an IME bug. This works fine using a physical keyboard with virtual keyboard disabled (by going Settings > Languages & input > Physical keyboard > disable "Show virtual keyboard"), but as soon as I show virtual keyboard, it doesn't work.
,
May 30 2016
Re #4, yes it is. Changed component. Physical keyboards (on both desktop and on Android) send a backspace key while IME goes through an API which eventually leads to InputMethodController::extendSelectionAndDelete. FYI, I'm trying to find a way to emit a replacement character for read-only elements for IME purposes (and struggling with backward compatibility issues).
,
Jul 13 2016
FYI, the current version of Google IMEs (Latin, Korean, Indic, etc) changed their behavior to send key event instead of calling deleteSurroundingText(). So it deletes read-only span correctly. However, the upcoming version shows significantly different behavior, and there are other issues around selection and deletion of read-only SPAN.
,
Jul 15 2016
Yeah, my concern is that even if we fix one issue with read-only spans, we'll find many more bugs down the line. I'm not sure how far the hole goes and there aren't that many use cases for it right now.
,
Jan 2 2017
,
Aug 21 2017
Facebook mobile site has issues when using Android keyboard (gboard). If I try to delete a mention, chrome just copies the last part of the name and don't delete it. On HubSpot I can't use mentions on Chrome for Android when using soft keyboard, but it works well with physical keyboards.
,
May 12 2018
I'm running into this issue as well. It's causing me a lot of pain with my rich text editor. I'm not seeing any backspace events either for a workaround. Would you consider this a Chromium bug or a GBoard bug?
,
May 15 2018
This issue isn't just with backspace. If you place the cursor at the end of the red block and press a key, it will copy the last word of the red block and append the letter you pressed to it. If you keep typing, more craziness ensues.
,
May 15 2018
unassigning myself as I'm not working on it.
,
May 19 2018
I can repro what ccorcos@ and gmarques@ mentioned, which looks definitely wrong to me when deleting brings texts back. However, it is unclear to me which is the correct behavior. On Chrome desktop, we can delete the whole contenteditable="false" element at once. On the other hand, with FireFox desktop (Linux), it doesn't allow me to delete. Web spec doesn't say too much about this. I think we probably want to support the same to Chrome desktop though.
,
May 19 2018
I think deleting the whole element is the right way to go. That way its easy to embed mentions and other rich content inside a contentEditable editor. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dennis.c...@gmail.com
, May 17 2016