NEW 20288
editable span with empty text gets optimized away 
https://bugs.webkit.org/show_bug.cgi?id=20288
Summary editable span with empty text gets optimized away
Bernhard Rosenkraenzer
Reported 2008-08-05 05:48:28 PDT
In the following test case: ================= <html> <head><title>test</title></head> <body> <div contenteditable="true"> <span contenteditable="false">Enter some text:</span> <span id="bug"> </span> </div> </body> </html> ================= The span with id "bug" should be editable - but there is no way to edit it because it gets optimized away. Even trying to force it with document.getElementById('bug').focus(); doesn't trigger any edit action on the span. Forcing the span to have non-zero width and height with CSS (<span id="bug" contenteditable="true" style="width: 10cm; height: 10cm;"></span>) doesn't change anything either. Adding any non-whitespace text inside the span does help.
Attachments
Add attachment proposed patch, testcase, etc.
Glenn Wilson
Comment 1 2008-08-13 11:10:14 PDT
I would argue that this is not a bug. Collapsing whitespace is the default behavior of CSS2.1 text, and typically what is expected. You can specify style="white-space:pre;" and the space will be drawn and you can edit it... Try this: ================= <html> <head><title>test</title></head> <body> <div contenteditable="true"> <span contenteditable="false">Enter some text:</span> <span style="white-space:pre;" id="bug"> </span> </div> </body> </html> =================
Ahmad Saleem
Comment 2 2022-06-21 13:18:18 PDT
I changed the test case from Comment 01 into following JSFiddle: Link - https://jsfiddle.net/mec6rb79/show I noticed following behavior: **Safari 15.5 on macOS 12.4: 1) Allows you to edit and caret shows at right place and you can type anything - not just "non-whitespace text" as mentioned in Comment 01. 2) But as soon as you do "backspace" to remove text and as soon as you remove last character, the caret jumps to opposite side like it is RTL language. **Chrome Canary 105: 1) Allows you to edit and caret shows at right place and you can type anything - not just "non-whitespace text" as mentioned in Comment 01. 2) But as soon as you do "backspace" to remove text and as soon as you remove last character, the caret disappear. **Firefox Nightly 103: It just simply does not allow you to edit at all. Since all browser have different behavior. I am not sure, what is expected behavior and ideally, which one should Safari follow. Appreciate if someone can look into it. Thanks!
Note You need to log in before you can comment on or make changes to this bug.