Closed Bug 613223 Opened 11 years ago Closed 7 years ago
Copy'n'pasting a string replaces non-breaking spaces by spaces
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.
You mean that a tab in a textarea or an input is submitted as a space instead of a tab for example?
What does this have to do with form submission?
Component: HTML: Form Submission → Editor
QA Contact: form-submission → editor
> 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.
Does it become a regular space just in the submitted value? Or also in the .value of the textarea in the DOM?
(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...
> 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.
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.
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.
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
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.
This is a dupe of #359303
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 359303
You need to log in before you can comment on or make changes to this bug.