603579 - textarea: soft hyphens are not editable individually

Status: NEW

(Core :: DOM: Editor, defect, P5)

Description

[Stefan]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20100101 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20100101 Firefox/4.0b8pre

In Firefox soft hyphens (­ ­) are "tied" to the preceeding character while they are usually treated as individual characters.

Reproducible: Always

Steps to Reproduce:
1. open the testcase
2. click evaluate (third character is a soft hyphen)
3. position cursor at the first character of the textarea
4. press DEL two times
5. click evaluate
Actual Results:  
ry­lo...

Expected Results:  
­ry­lo...

1. There are lines which end with a visible (soft) hyphen. Trying to delete the character in front of such a hyphen always leads to the deletion of that character plus the soft hyphen.

2. The text cursor does not "rest" on the soft hyphen when iterating thru a word. Google Chrome, KDE Konqueror or OpenOffice indicate the presence of a soft hyphen by "resting" when iterating thru a word which contains soft hyphens.

Comment 1

[Stefan]

Attachment: testcase

Comment 2

[Nickolay_Ponomarev]

I see this on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b8pre) Gecko/20101108 Firefox/4.0b8pre

Comment 3

[(no longer active)]

The reason that we extend the selection to include the soft hyphen here is this code: <http://hg.mozilla.org/mozilla-central/annotate/6eef4ea21123/layout/generic/nsTextFrameThebes.cpp#l5585>.  The IsAcceptableCaretPosition call returns false because the original char is skipped.  roc: do you know why we do that check?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We want the caret to skip over collapsed whitespace.

We want the caret to ignore soft hyphens that aren't visible. I agree it would be good to allow the caret to stop after a soft hyphen that is visible. But you'd have to be careful to ensure that nothing unexpected happens if the caret stops after a soft hyphen that is visible and then the content is reflowed so the hyphen is no longer visible, and then the user presses left or right again.

Comment 5

[(no longer active)]

Do we have any central place in the code where one would adjust the caret position if it's not acceptable?  I think the easiest way to solve this would be to stop checking IsCaretPositionAcceptable for delete, and then call such a function when we're done.  That should not make us worse in terms of caret placement when soft hyphens are in play, right?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Oh, I completely misunderstood this bug. Sorry.

I actually think item 2 in comment #0 is not a bug in general. Having editing commands appear to do nothing is confusing for users.

I think item 1 in comment #0 is also probably not a bug in general. I can't think of a behavior that would overall be better. If you're changing the text of a word, leaving soft hyphens in the word is no more likely to be correct than removing them.

Those comments apply to *invisible* soft hyphens. As I said in comment #4, we probably should return true for IsAcceptableCaretPosition for a visible soft hyphen.

If you want sensible editing of text containing soft hyphens, then you have to make them visible somehow. We'd probably have to add some kind of new CSS feature to enable that, perhaps a CSS pseudo-class ::character(NNNN) so you could write something like
[contenteditable]::character(173) {
  content: url(soft-hyphen.png);
}
and all such characters would then be ok for IsAcceptableCaretPosition.

Comment 7

[(no longer active)]

(In reply to comment #6)
> Oh, I completely misunderstood this bug. Sorry.
> 
> I actually think item 2 in comment #0 is not a bug in general. Having editing
> commands appear to do nothing is confusing for users.

Hmm, I think the real problem here is the invisibility of the soft hyphen...

> I think item 1 in comment #0 is also probably not a bug in general. I can't
> think of a behavior that would overall be better. If you're changing the text
> of a word, leaving soft hyphens in the word is no more likely to be correct
> than removing them.

Same here.

> Those comments apply to *invisible* soft hyphens. As I said in comment #4, we
> probably should return true for IsAcceptableCaretPosition for a visible soft
> hyphen.

How can I distinguish between the two?

> If you want sensible editing of text containing soft hyphens, then you have to
> make them visible somehow. We'd probably have to add some kind of new CSS
> feature to enable that, perhaps a CSS pseudo-class ::character(NNNN) so you
> could write something like
> [contenteditable]::character(173) {
>   content: url(soft-hyphen.png);
> }
> and all such characters would then be ok for IsAcceptableCaretPosition.

Can't we just modify the code which decides whether to show/hide soft hyphens to always show them for editable nodes, or something to that effect?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think you'd want to distinguish soft hyphens from normal hyphens visually. We could hard-code something but I think CSS control like my proposal above would be better, since it gives a lot more power to people developing editors.

You can identify a visible soft hyphen because the text frame has TEXT_HYPHEN_BREAK and the soft hyphen is the last character mapped by the text frame.

Comment 9

[Stefan]

I have been asked to review my bugs so I would like to ask why this bug is still in UNCONFIRMED state.

Comment 10

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.