textarea: soft hyphens are not editable individually

RESOLVED INACTIVE

Status

()

Core
Editor
RESOLVED INACTIVE
8 years ago
16 hours ago

People

(Reporter: Stefan, Unassigned)

Tracking

({testcase})

Trunk
x86_64
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [post-2.0])

Attachments

(1 attachment)

1.14 KB, text/html
Details
(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
Created attachment 482495 [details]
testcase

Comment 2

8 years ago
I see this on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b8pre) Gecko/20101108 Firefox/4.0b8pre
Component: General → Editor
Keywords: testcase
Product: Firefox → Core
QA Contact: general → editor
Version: unspecified → Trunk

Comment 3

8 years ago
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?
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

8 years ago
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?
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

8 years ago
(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?
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.

Updated

8 years ago
Whiteboard: [post-2.0]
(Reporter)

Comment 9

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

Updated

3 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All

Comment 10

16 hours ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 16 hours ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.