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

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

-> 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.

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.

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.

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.

This testcase does not reproduce the same reported bug.

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

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

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.

"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.