273106 - Soft hyphens (­) results in weird marking of words

Status: RESOLVED DUPLICATE of bug 213408

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

Description

[Peter Brodersen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

If one uses soft hyphens in a text - ­ - the soft hyphen isn't rendered
(which is okay), but the offset of marked text after the soft hyphen is skewed.


Reproducible: Always
Steps to Reproduce:
1. Create a HTML-page with the following text: Th­is text is yet
an­other example of text that is fun­ny to mark. Double­click
somewhere around here or here or here. Or mark and copy some text and paste it
into another document.
2. Mark some text or doubleclick at a word
3. Copy the text into another document

Actual Results:  
When manually marking some text such as "somewhere", it actually copies "ick somew".

When doubleclicking on (left side of) "somewhere", "bleclick some" is visually
marked, but "somewhere" is actually copied.

Expected Results:  
When manually marking some text such as "somewhere", it should copy "somewhere".

When doubleclicking on "somewhere", "somewhere" should be visually marked and
copied.


This might be related to bug #213408 (although this bug mainly concerns whether
or not the shy-character should be included in the copied text) and bug #241486
(that concerns about the offset in a textarea). I'm not sure whether or not this
bug should just be appended to these bugs or held as a seperate bug.

Comment 1

[Gérard Talbot]

DUP of bug 9101 ?

Comment 2

[Justin Wood (:Callek)]

I dont think it is a dupe of the bug listed in c#1...though this may still be a
dupe, marking new simply because I experience this in current trunk
nightly...and adding DUPEME to whiteboard, just in case

Comment 3

[Boris Zbarsky [:bzbarsky]]

Callek, this is almost certainly in the wrong component.  Depending on what the
selection looks like (I mean the selection DOM range) for this case, it's either
a selection bug or a dom-to-text bug.

Since you confirmed this, assigning to you to test and reassign appropriately.

Comment 4

[Uri Bernstein]

Dupe of bug 213408?

Comment 5

[Justin Wood (:Callek)]

Original Bug, as described in URL is INVALID now (fixed by some unknown means);
 Though a similar underlying issue is at Bug 213408 as suggested as a dupe. 
Marking Dupe for that reason.

*** This bug has been marked as a duplicate of 213408 ***