Bug 20288 - editable span with empty text gets optimized away
Summary: editable span with empty text gets optimized away
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: All Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-05 05:48 PDT by Bernhard Rosenkraenzer
Modified: 2022-06-21 13:41 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Rosenkraenzer 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.
Comment 1 Glenn Wilson 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>
=================

Comment 2 Ahmad Saleem 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!