213408 - Problems selecting, copying and pasting text containing soft hyphens (­)

Status: RESOLVED INCOMPLETE

(Core :: Layout: Text and Fonts, defect)

Description

[Mathias Aebischer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

When doubleclicking on the word "NumberFormatException" inside the floating text
"NumberFormatException, " is marked. After holding down shift and clicking the
left arrow twice "NumberFormatException ?" is marked instead of
"NumberFormatException". the problem seems to have something to do with the
bold-tags around this word. i also had problem when i copied the text into this
textarea and tried to edit it. instead of "NumberFormatException" in other
programs i get "Number-Format-Exception".

Reproducible: Always

Steps to Reproduce:
1.doubleclick on bold word "NumberFormatException"
2.hold shift while clicking on left arrow
3.copy & paste text

Actual Results:  
question mark appears

Number-Format-Exception is pasted

Expected Results:  
no question mark should appear

NumberFormatException should be pasted

Comment 1

[Boris Zbarsky [:bzbarsky]]

The text contains ­ entities, which explains the '-' chars you see...

Comment 2

[Jon Henry]

-> Layout: Fonts and Text, as this relates to glyph substitution.

I think the reporter has a point that these glyphs should not be put into the
clipboard when copied. Especially since, until bug 9101 is fixed, Mozilla
doesn't honor the soft hyphen anyway so their presence is especially confusing.
Soft hyphens should only appear when a word is broken, and that is only a
product of how it's layed out. It seems to me the user would, in pretty much all
cases, want to copy the words but not the hyphen, since they are probably not
copying it to a document where the word will break in exactly the same place. I
think this bug is valid.

Comment 3

[Jon Henry]

Tweaking summary.

There is a definite graphical glitch associated with double-clicking to select
text that contains a soft-hyphen. This does not appear when dragging to select,
only double clicking. Garbled text to the right of the selection appears.
Perhaps these should be in two seperate bugs.

Comment 4

[Mike Cowperthwaite]

I agree the graphical glitch is a bug.

I disagree that the ­ should be omitted from the copied text.

I disagree that this belongs in the tracking bug for Line Breaking problems.

Comment 5

[Jungshik Shin]

I agree that SHY should be inclueded in copy because it's a 'discretionary'
hyphen. If it doesn't fall on a line boundary in the copied text, it's the
responsibility of a 'recipient' _not_ to render it visibly.

There's another SHY-like character for Mongolian(?) script in Unicode. As a
reminder to that, I'm mentioning it and adding intl kwd.

Comment 6

[Bert]

Attachment: testcase

This testcase does not reproduce the same reported bug.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

*** Bug 294619 has been marked as a duplicate of this bug. ***

Comment 8

[Justin Wood (:Callek)]

*** Bug 273106 has been marked as a duplicate of this bug. ***

Comment 9

[j.j.]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090604 Minefield/3.0a8pre

testcase attachment (id=142223)
If I copy & paste "ab" or "cd" into the textarea, there is an additional space after the text. 

Comment 10

[Stefan]

"additional space after the text": That is not related to the soft hyphens. It seems to occur when 'X+\n+<br>', where X is the selected text, is in the source.

Comment 11

[Alin Ilea, Desktop Test Engineering]

Marking this as Resolved > Incomplete since the last activity on this issue was 11 years ago and it might not be relevant anymore. Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.

Comment 12

[yorickvanpelt]

This bug is still unsolved on firefox 94.0b2. I don't think I have permission to re-open, but please re-open.

Comment 13

[Jonathan Kew [:jfkthame]]

I just tried a couple of tests here and did not see any unexpected behavior. Note that the "additional space" when pasting as described in comment 9 is not related to soft-hyphens; it results from the newline character (as mentioned in comment 10) being included in what's selected/copied.

But this bug has discussed several separate things, making it hard to know exactly what is or isn't solved.

It would be best to file a new bug with a specific testcase and description of any remaining issues you're seeing, rather than add to the mixture of old discussion here.