613223 - Copy'n'pasting a string replaces non-breaking spaces by spaces

Status: RESOLVED DUPLICATE of bug 359303

(Core :: DOM: Core & HTML, defect)

Description

[Scoobidiver (away)]

Build: Mozilla/5.0 (Windows NT 6.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

If you copy a string that contains non-breaking spaces, pasting it replaces non-breaking spaces by spaces.
This bug is an old one. See bug 218277 comment 96.

Comment 1

[Mounir Lamouri (:mounir)]

You mean that a tab in a textarea or an input is submitted as a space instead of a tab for example?

Comment 2

[Boris Zbarsky [:bzbarsky]]

What does this have to do with form submission?

Comment 3

[Scoobidiver (away)]

> You mean that a tab in a textarea or an input is submitted as a space instead
> of a tab for example?
I don't mean a tab, I mean a non-breaking space (Alt+0160 on Windows).
If you type a non-breaking space in a textarea, it will be submitted as a non-breaking space. There is no problem for that. See bug 218277 for the fixing.

If you select in an editor a string that contains a non breaking space, when you paste it in the same editor the non-breaking space becomes a space.

First, I guessed it was a Windows clipboard bug, but I can copy'n'paste strings with non-breaking space in OpenOffice without any problem. So, it is probably a Firefox bug.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Does it become a regular space just in the submitted value?  Or also in the .value of the textarea in the DOM?

Comment 5

[Mounir Lamouri (:mounir)]

(In reply to comment #3)
> > You mean that a tab in a textarea or an input is submitted as a space instead
> > of a tab for example?
> I don't mean a tab, I mean a non-breaking space (Alt+0160 on Windows).

Oups, i thought you mean non-breaking line non line-break.

> If you type a non-breaking space in a textarea, it will be submitted as a
> non-breaking space. There is no problem for that. See bug 218277 for the
> fixing.

You chose the Form Submission component so I thought it was linked with
submission...

Comment 6

[Scoobidiver (away)]

> Does it become a regular space just in the submitted value?  Or also in the
> .value of the textarea in the DOM?
If I paste the copied textarea either in the text editor or in the OpenOffice Writer, every non-breaking spaces are replaced by regular spaces. So the problem is in copying the textarea into the DOM.

Comment 7

[(no longer active)]

This doesn't have anything to do with the editor, it's a bug in the document encoder.

To test this, open the test case, first select the text inside the testarea, paste it in the input element and click Test.  The alert shows 32, whereas the correct value should be 160.  Then repeat the same steps with the "a b" below the textarea, and the same value (32) is alerted again.

Comment 8

[Scoobidiver (away)]

Here is a little context:
French punctuation rules say there must be a non-breaking space before a double punctuation such as :, ;, ?, !, » (left angle quote) and after « (right angle quote) (see https://fr.wikipedia.org/wiki/Ponctuation#Les_espaces_autour_des_signes_de_ponctuation_.28r.C3.A8gles_actuelles.29).
In Wikis such as SUMO or Wikipedia, copying/pasting is often used and can cause missing non-breaking spaces before double punctuations.

Comment 9

[Nicolas Barbulesco]

That's true in English too, although to a lesser extent. With good typography, we write non-breaking spaces in phrases like these, for instance :

3_km
20th_century
Elizabeth_II
Dr._Sattler
H._Melville

Comment 10

[Martin Trautmann]

Looks like the old bug https://bugzilla.mozilla.org/show_bug.cgi?id=359303 (and https://bugzilla.mozilla.org/show_bug.cgi?id=483762)

Confirmed for MacOS, too.

I guess it was considered as a feature, but I feel it's a bug.
Non breaking space should be used between numbers and units - not possible here.

Comment 11

[Mina]

This is a dupe of #359303