Non-breaking spaces (nbsp) not copied as such
Categories
(Core :: DOM: Serializers, defect)
Tracking
()
People
(Reporter: cody, Assigned: kemenaran)
References
(Blocks 1 open bug)
Details
(Keywords: dataloss)
Attachments
(3 files)
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Comment 2•18 years ago
|
||
Comment 3•18 years ago
|
||
Comment 5•18 years ago
|
||
Comment 6•17 years ago
|
||
Comment 7•17 years ago
|
||
Comment 8•17 years ago
|
||
Comment 9•17 years ago
|
||
Comment 10•17 years ago
|
||
Comment 11•17 years ago
|
||
Comment 12•17 years ago
|
||
Reporter | ||
Comment 13•17 years ago
|
||
Comment 14•17 years ago
|
||
Comment 15•17 years ago
|
||
Comment 16•17 years ago
|
||
Comment 17•15 years ago
|
||
Comment 18•15 years ago
|
||
Comment 19•15 years ago
|
||
Updated•15 years ago
|
Comment 20•15 years ago
|
||
Comment 21•15 years ago
|
||
Comment 22•15 years ago
|
||
Comment 23•15 years ago
|
||
Comment 24•14 years ago
|
||
Comment 25•14 years ago
|
||
Comment 26•14 years ago
|
||
Comment 27•14 years ago
|
||
Comment 28•13 years ago
|
||
Comment 29•11 years ago
|
||
Comment 30•11 years ago
|
||
Comment 32•11 years ago
|
||
Comment 33•11 years ago
|
||
Comment 34•11 years ago
|
||
Comment 36•11 years ago
|
||
Comment 37•10 years ago
|
||
Comment 38•10 years ago
|
||
Comment 39•9 years ago
|
||
Comment 40•9 years ago
|
||
Comment 42•8 years ago
|
||
Comment 43•8 years ago
|
||
Comment 44•6 years ago
|
||
Comment 45•6 years ago
|
||
Comment 46•6 years ago
|
||
Comment 47•6 years ago
|
||
Comment 48•6 years ago
|
||
Comment 49•6 years ago
|
||
Comment 50•6 years ago
|
||
Comment 51•6 years ago
|
||
Comment 52•6 years ago
|
||
Comment 53•6 years ago
|
||
Comment 54•6 years ago
|
||
When will this bug finally get solved? I always have to use Chrome when I want to paste text containing non-breaking spaces into a website.
There are so many duplicates that are marked as resolved but are not solved in any way.
This bug should also be added as a duplicate because it is the same problem: https://bugzilla.mozilla.org/show_bug.cgi?id=268995
Comment 55•6 years ago
|
||
No, in bug 268995, a copy is not involved: the nbsp came from the original form data and was not copied or pasted.
Comment 56•6 years ago
|
||
Oh, I see. But then this bug is still annoying and also rated as critical since quite a while.
So please taka a look at it again. I am sure this can be solved quite fast. Unfortunality I am not enough experienced to create a patch for this issue by myself.
Comment 57•6 years ago
|
||
This bug is, in fact, trivial to fix, and the attach patch does this (a trivial adaptation of a patch already attached to bug #194498 — which see also).
The reason is that it's not so much a bug as an intentional misfeature: it's not that Firefox accidentally breaks U+00A0 NO-BREAK SPACE (=:NBSP), it's that somebody deliberately decided that it should, and added explicit code to do it. The logic behind the code is that HTML composer sometimes turns some U+0020 SPACE (when there are multiple in a row, or something) into U+00A0 NO-BREAK SPACE and the fear is that pasting them as such would break things.
I think this logic is bad in every sense. Every bit of code which turns U+00A0 NO-BREAK SPACE into U+0020 SPACE or vice versa should be removed, and Firefox should always remain Unicode-transparent. (A middle ground, if fear of breaking things is so great, would be to make this a user-settable preference. I don't know how to do this.) But I don't know who makes these decisions or how to contact them or how to argue about this; I'm pretty sure they don't read this kind of bug reports, however, so it's useless to discuss it here.
In the mean time, I simply apply the patch when compiling Firefox.
Comment hidden (admin-reviewed) |
Comment 59•6 years ago
|
||
Comment 60•5 years ago
|
||
I registered here just to express my support for the change.
A program should not mangle data, unless there is some really good reason - which i do not see here.
Comment 61•5 years ago
|
||
We’re are now in 2019, almost 20 years after the year 2000, and Unicode is now well supported in every OS. This conversion was a bad idea from the very beginning, 13 years after it’s a complete non-sense.
I can type in non-breaking and thin spaces ( ) with my keyboard, but when I paste a text containing such characters in a Firefox form input, I lose the non-breaking spaces, whereas the thin spaces are kept. Do you really see a good reason for this design?!
As a french corrector, I use an external text editor (Gedit) that can display spaces and draw these special spaces differently. I make some automatic corrections to comply with the French orthotypographic rules, and some of these corrections are the replacement of certain spaces by non-breaking and thin spaces. As you can guess, when I copy the corrected text from my editor and then paste it to Firefox, I lose all the non-breaking spaces. :-( It’s a big waste of time!
So please, consider removing this useless, bad and annoying conversion of the non-breaking spaces. As a benefit, you will remove a couple lines of code and you will save a few CPU cycles when pasting text in form inputs.
No caveats, just benefits. So, please, what are you waiting for?…
Comment 62•5 years ago
|
||
What do you think, Masayuki-san, should we remove
https://searchfox.org/mozilla-central/rev/ab6f4c453d15ab82147c630a8b886b40240ca72b/dom/base/nsPlainTextSerializer.cpp#1143-1147
as suggested in attachment 9060386 [details] [diff] [review]?
Comment 63•5 years ago
|
||
(In reply to Jorg K (GMT+2) from comment #62)
What do you think, Masayuki-san, should we remove
https://searchfox.org/mozilla-central/rev/ab6f4c453d15ab82147c630a8b886b40240ca72b/dom/base/nsPlainTextSerializer.cpp#1143-1147
as suggested in attachment 9060386 [details] [diff] [review]?
The change would break copy in HTML editor. In HTML editor without <pre>
element, 2nd and later ASCII whitespaces are automatically converted to NBSPs since if web browsers don't do that, whitespace collapsing of HTML spec causes only one whitespace rendered. Unfortunately, we cannot distinguish whether every NBSP in an editable text node is truly NBSP or not (i.e., automatically converted one). Therefore, we cannot fix this bug without big changes in HTML editor. However, in non-editable content, not so. So, if nsPlaintextSerializer
handles NBSPs when it retrieves text from a node, we can fix this for non-editable content.
Comment 64•5 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still struggling with the pain, but becoming better) from comment #63)
- Is there any reason to preserve multiple spaces? Formatting with spaces (typewriter-like) is generally a bad idea, since it is not reproducible, and there are more proper ways for indentation and alignment.
- If preserving them is necessary, doesn't you HTML support the
white-space: pre-wrap
style?
Comment 65•5 years ago
|
||
(In reply to Mikhail Ryazanov from comment #64)
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still struggling with the pain, but becoming better) from comment #63)
- Is there any reason to preserve multiple spaces? Formatting with spaces (typewriter-like) is generally a bad idea, since it is not reproducible, and there are more proper ways for indentation and alignment.
- If preserving them is necessary, doesn't you HTML support the
white-space: pre-wrap
style?
Not to mention that, for people trying to produce rich-text inputs that are both well-formed and non-confusing to users (ie. me), it's a pain to have to write and debug JavaScript which replicates LyX's behaviour of discarding Space of Enter keypresses if they'd cause the editor view to abuse semantic markup to insert presentational whitespace (eg. non-breaking spaces and empty paragraph tags).
Comment 66•5 years ago
•
|
||
(In reply to Mikhail Ryazanov from comment #64)
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still struggling with the pain, but becoming better) from comment #63)
- Is there any reason to preserve multiple spaces? Formatting with spaces (typewriter-like) is generally a bad idea, since it is not reproducible, and there are more proper ways for indentation and alignment.
Most users don't know:
- whether current editor is HTML editor (
contenteditable
ordesignMode
) or Text Editor (<input>
or<textarea>
). - how multiple whitespaces are treated in HTML editor (without
<pre>
).
Therefore it makes sense to make typed multiple ASCII whitespaces look as-is.
- If preserving them is necessary, doesn't you HTML support the
white-space: pre-wrap
style?
Ideally yes, but all browsers converts whitespaces to NBSPs:
- https://searchfox.org/mozilla-central/rev/3366c3d24f1c3818df37ec0818833bf085e41a53/editor/libeditor/WSRunObject.cpp#376-387
- https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/editing/editing_utilities.cc?l=109-135&rcl=bceef7a94ae50ee87b9753142eab2b669be96552
Therefore, we cannot take another approach anymore from point of view of web-compat.
Therefore, I think that we should keep converting NBSPs in editable elements (contenteditable
or designMode
), but I think we shouldn't convert in non-editable elements or <input>
/<textarea>
to make users can treat raw data. So, I think that patch may break something of the former case.
Comment 67•5 years ago
|
||
Let me reiterate what I suggested in a comment above: why not make this a user-settable preference? So experienced users who know what an unbreakable space is and care about it can set this preference and Firefox's behavior would then be transparent in every respect (in the editor and while copying and pasting, every character would be retained exactly as it is, including multiple spaces), whereas the default behavior would be either the current one, or some other compromise.
I don't know enough about how Firefox works to code this myself, but I imagine it would be fairly trivial for someone who knows: at least, it doesn't add any significant amount of complexity.
Comment 68•5 years ago
|
||
I agree with David that a user-settable preference would be a pretty good compromise until a better solution is found. And it’s only a couple lines of code. Ignoring the problem shouldn’t be an option anymore.
Comment 69•5 years ago
|
||
My main concern here is composing mail in Thunderbird. Will not converting in non-editable element fix that? Because I cannot type french correctly without NBSP support in Thunderbird, and that has been quite an issue for years. I trick it by using NWNBSP, but that is far from ideal.
Comment 70•5 years ago
•
|
||
If a NBSP is alone, we can stop converting it even in editable contents. E.g., <p>foo bar</p>
.
Comment 71•5 years ago
|
||
I'm not a native speaker of any Western languages so that I don't know how NBSP is used in actual usage. Is that used continuously like foo bar
?
Comment 72•5 years ago
•
|
||
See comment #26 and comment #46 under "French typography", for example: « like this »
Comment 73•5 years ago
|
||
No, actually this is a great idea, I don’t know any language where you are supposed to have multiple ones in a row. In french you use it before colons, within quotes and for « incises » mostly, like this « Une idée : ne pas remplacer les espaces insécables uniques — pour lesquelles ça ne changerait a priori rien pour le rendu et qui sont en revanche l’utilisation légitime la plus probable. ». So yes, that would work for french at least.
Comment 74•5 years ago
|
||
(In reply to Bruno Pagani from comment #73)
No, actually this is a great idea, I don’t know any language where you are supposed to have multiple ones in a row. In french you use it before colons, within quotes and for « incises » mostly, like this
« Une idée : ne pas remplacer les espaces insécables uniques — pour lesquelles ça ne changerait a priori rien pour le rendu et qui sont en revanche l’utilisation légitime la plus probable. »
. So yes, that would work for french at least.
Of course those NBSP in my comment have been converted to display, so I’m quoting myself and putting the french excerpt in code formatting just above.
Comment 75•5 years ago
|
||
+1 to that heuristic: If NBSP is encountered adjacent to another NBSP or to an ordinary SPACE, assume it is used for alignment/indentation and convert it to a SPACE. Otherwise, assume it is used in its intended function and leave it alone.
Comment 76•5 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(no pain of the broken bone, but the corset blocks me to concentrate) from comment #71)
I'm not a native speaker of any Western languages so that I don't know how NBSP is used in actual usage. Is that used continuously like
foo bar
?
I'm not an expert on every European language but, in my experience, there are three ways
gets used:
-
Official language rules of the type that has already been mentioned. I've never heard of any of these situations requiring more than one non-breaking space in a row. (The closest thing that comes to mind is the typewriter-era rule that you type two spaces after a sentence-ending period when using a monospace font to make it easier to see sentence boundaries in among all the whitespace that isn't getting kerned away. Aside from that, the convention was to invent new types of space characters rather than typing multiple of an existing one to ensure that the typeface would preserve the desired proportional relationships and, in the case of digital typography, the semantic meanings.)
-
Replacing what would otherwise be a normal space in order to manipulate where a line may break without help from whoever is developing the CMS or forum software. (eg. Putting
between the last two/few words in a paragraph to so word-wrapping will treat them as a single word. This is done as a way of preventing what typesetters call "orphans"... basically, when a paragraph's last line is so short that it gives the impression of the paragraph break being too tall.) -
A chain of to subvert the stylesheet's rules for how text should be displayed. (Pranksters used to try to feed this into comment forms to force a page to be wider than the viewport.)
Only the third option requires multiple non-breaking spaces in a row.
Comment 77•5 years ago
|
||
I disagree about the heuristic as this will introduce confusion (e.g. users thinking that nbsp are preserved, but in some particular cases, they actually aren't). A user-settable preference would be better.
Comment 78•5 years ago
|
||
(In reply to Vincent Lefevre from comment #77)
I disagree about the heuristic as this will introduce confusion (e.g. users thinking that nbsp are preserved, but in some particular cases, they actually aren't). A user-settable preference would be better.
Which is still better than what we have today, because there is no indication that NBSP are discarded in a lot of cases, and you might only see it after e.g. receiving a copy of your message that has been wrapped to 80 chars for instance.
Comment 79•5 years ago
|
||
In our case we use non-breaking spaces between words and numbers like "page 35" or "article 5" or "§ 50" and so on. In our company we develop web applications to convert text of any kind to a well layouted ready-to-print PDF or other formats. It happens all the time that someone copies text containing non-breakable spaces into our application with the intent that the spaces will be preserved as is after submitting the form.
At the moment this only works in other browsers than Firefox. Our issue really is only submitting forms.
Comment 80•5 years ago
|
||
Another use, in French, is to avoid a number being separated from its unit:
- « L’altitude du Mont Everest est de 8 848[non breaking space]mètres ».
But a thin space ( ) is used when the unit symbol is used (the thin space is also the thousands separator):
- « altitude du Mont Everest : 8 848 m ».
Comment 81•5 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(no pain of the broken bone, but the corset blocks me to concentrate) from comment #63)
The change would break copy in HTML editor. In HTML editor without
<pre>
element, 2nd and later ASCII whitespaces are automatically converted to NBSPs [...]
This is completely broken! I've just received a mail written from Firefox in something like a webmail, containing C code. This C code (as very often) contains multiple consecutive spaces for indenting. But in the mail, all spaces except the last one were converted to NBSPs. And as C code, this is invalid!
Comment 82•5 years ago
|
||
Another example: it's impossible to use Transifex (https://www.transifex.com/) for correct French translation since Firefox keeps changing nbsp's into normal spaces.
Quite disappointing that this bug is still here.
Comment 83•5 years ago
|
||
The nbsp is used as a typographic treatment in many European languages. When a text is typeset, nbsp prevents unwanted line break between the characters or words (e.g. nbsp is placed between single-letter word and the following word). The fact that Firefox as the only browser deliberately removes nbsp from textarea/input forces users to switch between browsers when they’re addressing typography on the web. Tools such as https://typopo.tota.sk (automatic correction of typography errors) do not work in Firefox since one of their jobs is to place non-breaking spaces properly. I’d say the solution as suggested in comment 57 would be the best option to solve this problem.
Comment hidden (advocacy) |
Updated•5 years ago
|
Comment 85•5 years ago
|
||
Bonjour David,
I am not saying that the patch would be accepted but managing preferences is pretty easy to do in Firefox.
Would be interested to propose a patch? I can help internally to find a reviewer and find help if needed.
We have also a step by step new contribution tutorial now:
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
merci
Comment 86•5 years ago
|
||
I build Firefox with David’s patch for my personal use, and I have to say that some code syntax highlighters and markdown processors out there have become addicted to this corruption of non-breaking spaces by browsers. E.g. when somebody sends a block of code over Slack, and I copy it to my editor, I get nbsps in indentation. So some heuristic to only convert spans of multiple adjacent nbsps would be desirable.
Comment 87•5 years ago
|
||
(In reply to Yuri Khan from comment #86)
I build Firefox with David’s patch for my personal use, and I have to say that some code syntax highlighters and markdown processors out there have become addicted to this corruption of non-breaking spaces by browsers. E.g. when somebody sends a block of code over Slack, and I copy it to my editor, I get nbsps in indentation. So some heuristic to only convert spans of multiple adjacent nbsps would be desirable.
I think a Web browser should behave correctly at all times. Fixing Web pages designed by incompetent designers is their own problem.
Comment 88•5 years ago
|
||
I think a Web browser should behave correctly at all times. Fixing Web pages designed by incompetent designers is their own problem.
You’re right of course, but web browsers have not been allowed to choose correct behavior over backward bug compatibility since the Netscape/IE times. A partial fix now is preferable to a perfect fix never.
Comment 89•5 years ago
•
|
||
Yes, editor requires to put NBSPs if there are multiple white-spaces are adjacent because adjacent ASCII white-spaces are collapsed to an ASCII white-space at rendering time due to basic of HTML/SGML/XML spec unless parent element is explicitly styled as "preformatted" (Currently, I'm rewritting the normalizer to take similar behavior as Chrome). So, I think that only when an NBSP is not surrounded by another NBSP nor ASCII white-spaces, can say the NBSP is truly an NBSP. Unfortunately, as far as I've tested, you cannot insert multiple NBSPs in a place in contenteditiable
because web browsers cannot remeber which white-spaces were NBSPs. If browsers want to do that, browsers need to store x2 footprint per text node unfortunately.
Comment 90•5 years ago
•
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #89)
Yes, editor requires to put NBSPs if there are multiple white-spaces are adjacent because adjacent ASCII white-spaces are collapsed to an ASCII white-space at rendering time due to basic of HTML/SGML/XML spec unless parent element is explicitly styled as "preformatted"
I have always found this "feature" extremely annoying TBH. I use French spacing when typing and I hate to see one of them become non-breaking. I can type a non-breaking space all right whenever I need one.
Comment 91•5 years ago
|
||
(In reply to Yuri Khan from comment #88)
I think a Web browser should behave correctly at all times. Fixing Web pages designed by incompetent designers is their own problem.
You’re right of course, but web browsers have not been allowed to choose correct behavior over backward bug compatibility since the Netscape/IE times. A partial fix now is preferable to a perfect fix never.
I think a perfect fix (by removing the nbsp absurdity) would be easier than a partial fix in this case, so it should win the now/never contest.
Comment hidden (me-too) |
Comment hidden (me-too) |
Comment 94•4 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #63)
(In reply to Jorg K (GMT+2) from comment #62)
What do you think, Masayuki-san, should we remove
https://searchfox.org/mozilla-central/rev/ab6f4c453d15ab82147c630a8b886b40240ca72b/dom/base/nsPlainTextSerializer.cpp#1143-1147
as suggested in attachment 9060386 [details] [diff] [review]?The change would break copy in HTML editor. In HTML editor without
<pre>
element, 2nd and later ASCII whitespaces are automatically converted to NBSPs since if web browsers don't do that, whitespace collapsing of HTML spec causes only one whitespace rendered. Unfortunately, we cannot distinguish whether every NBSP in an editable text node is truly NBSP or not (i.e., automatically converted one). Therefore, we cannot fix this bug without big changes in HTML editor. However, in non-editable content, not so. So, ifnsPlaintextSerializer
handles NBSPs when it retrieves text from a node, we can fix this for non-editable content.
I‘d like to apologize for my previous comment and offer something actually constructive.
If I understand both the discussion and the snippets of source code that have been posted here, on type/paste, Firefox converts SP characters (U+0030) into NBSP characters (U+00A0) in order to preserve apparent whitespace. This leaves no way to disambiguate between typed/pasted and automatically converted SP/NBSP characters.
What if automatically converted SP-to-NBSP characters were marked by preceding them with a zero-width joiner (U+200D ZWJ)? It would have no visible impact on the content presented on-screen but also could act as a flag for converting ZWJ NBSP back to plain SP on cut/copy in order to leave unmarked NBSP alone. Also, because it’s so apparently useless as a combination, ZWJ NBSP is extremely unlikely to appear anywhere for just about any reason, so it should be a reliably safe way to mark these spaces.
I‘d offer the code myself, but sadly the most sophisticated anything I’ve programmed was a violin tuner in BASIC about 25 years ago.
Comment 95•4 years ago
|
||
What if automatically converted SP-to-NBSP characters were marked by preceding them with a zero-width joiner (U+200D ZWJ)? It would have no visible impact on the content presented on-screen but also could act as a flag for converting ZWJ NBSP back to plain SP on cut/copy in order to leave unmarked NBSP alone. Also, because it’s so apparently useless as a combination, ZWJ NBSP is extremely unlikely to appear anywhere for just about any reason, so it should be a reliably safe way to mark these spaces.
The combinations of plain U+0020 SPACE with U+00A0 NO-BREAK SPACE is already as useless as possible for purposes other than indentation.
Comment 96•4 years ago
|
||
(In reply to Yuri Khan from comment #95)
What if automatically converted SP-to-NBSP characters were marked by preceding them with a zero-width joiner (U+200D ZWJ)? It would have no visible impact on the content presented on-screen but also could act as a flag for converting ZWJ NBSP back to plain SP on cut/copy in order to leave unmarked NBSP alone. Also, because it’s so apparently useless as a combination, ZWJ NBSP is extremely unlikely to appear anywhere for just about any reason, so it should be a reliably safe way to mark these spaces.
The combinations of plain U+0020 SPACE with U+00A0 NO-BREAK SPACE is already as useless as possible for purposes other than indentation.
That was kind of my point. Isn’t the problem we’re trying to solve here trying to balance the needs of lay users with the more typographically advanced? By marking which space characters were automatically converted on input so that they’re properly un-converted on output, we can have our proverbial cake and eat it, too. Automatically converting U+0030 ↔ U+200D U+00A0 achieves that.
Comment 97•4 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #66)
(In reply to Mikhail Ryazanov from comment #64)
- If preserving them is necessary, doesn't you HTML support the
white-space: pre-wrap
style?Ideally yes, but all browsers converts whitespaces to NBSPs:
I don't understand this comment. Why cannot Firefox choose to do it differently, in a better way?
Or couldn't there be a way to disable conversions between normal space and nbsp for users that don't need such conversions?
When the NBSP came from the site (as opposed to editor in Firefox), changing the NBSP is bad. Yet, it appears that Chrome, too, has the behavior that designMode
/ contenteditable
changes every other space into an NBSP when pressing the space bar multiple times and copying the text undoes the hack.
I think we should investigate what heuristic Chrome uses exactly, but off the top of my head, I suggest changing an NBSP to an ASCII space upon plain text clipboard export only if it is adjacent to an ASCII space. This would leave non-editor-generated NBSP intact, and I think it is a legitimate concern to want those to be left intact e.g. in the case of French quotation marks.
Chrome's editing code appears to also have a special case that if you delete an ASCII space that is adjacent to an NBSP, the NBSP turns into an ASCII space at that point.
Comment 99•3 years ago
|
||
Implemented the suggestion from the previous comment here:
https://github.com/Betterbird/thunderbird-patches/blob/main/91/bugs/359303-dont-replace-NBSP-m-c.patch
Assignee | ||
Comment 100•3 years ago
|
||
Would a Firefox patch based on the Thunderbird patch above be acceptable, and considered for review?
If so, I can submit a Firefox patch for this.
Comment 101•3 years ago
|
||
Pierre, the patch looks good but, i don't have the technical expertise on this.
Henri does
Rachel, could you please submit your patch for review:
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
Comment 102•3 years ago
|
||
(In reply to Pierre de La Morinerie from comment #100)
Would a Firefox patch based on the Thunderbird patch above be acceptable, and considered for review?
If so, I can submit a Firefox patch for this.
If you submit the patch, please follow our attribution policy (examples here). It's likely that Mozilla will request to add a test, like this one here. Please note that the initial version of the patch wasn't correct, we've rectified this now.
Assignee | ||
Comment 103•3 years ago
|
||
Attribution: the actual nsPlainTextSerializer changes were written by Rachel Martin <rachel@betterbird.eu>,
as a part of Betterbird.
Updated•3 years ago
|
Comment 104•3 years ago
|
||
Please add the following comment to the code:
/*
Mail composers enforce consecutive spaces in HTML output by replacing them with non-breaking spaces.
Revert this hack when converting HTML text to plain text.
*/
Thank you.
Comment 105•3 years ago
|
||
(In reply to Pierre de La Morinerie from comment #103)
Created attachment 9269182 [details]
Bug 359303 - preserve nbsps on clipboard export. r=hsivonen
Nice test. You might want to add test cases for nnns
where n is a NBSP and s is a regular space. That will test the left-promotion. For full test coverage we suggest nnns
, snnn
, nsns
, snsn
and maybe some random stuff like nnssnsnnsnn
or so. In all those cases, the NBSP should be replaced.
Assignee | ||
Comment 106•3 years ago
|
||
Thanks a lot for the suggestions. I added the comment, and updated the test with replacement examples.
I also updated the original code to use uints for length indexing (instead of ints), which makes the clang linter happy. This involved rewriting the indices of the second promotion loop (while retaining the same semantics).
Comment 107•3 years ago
|
||
It was not meant to be a structured comment. If you want it to be, you should probably use some comment tag.
Assignee | ||
Comment 108•3 years ago
|
||
I saw other functions in this file being described with the same kind of top-level comments, formatted similarly (e.g. nsPlainTextSerializer::CurrentLine::CreateQuotesAndIndent
). I think keeping this descriptive comment as a general function description (rather than in the function body) would be useful; which comment tag would you add to it?
Comment 109•3 years ago
|
||
It really depends on the comment structure that is used in a particular project. E.g. <summary>
. But I do not know which convention, if any, it used here. If there is no convention, it is best not to use structured comments at all for fear of future conflicts.
Assignee | ||
Comment 110•3 years ago
|
||
I reverted the comment to a non-structured comment (which seems the safest thing to do).
Chrome copies the characters as they are
What exactly do Chrome and Safari do? I tried copying from https://hsivonen.com/test/moz/nbsp.html in Chrome and pasting into gedit on Ubuntu, Notepad on Windows, and TextEdit on Mac. I also copied from Safari and pasted into TextEdit.
AFAICT, in all four cases all no-break spaces got replaced by regular spaces. What am I missing?
Attribution: the actual nsPlainTextSerializer changes were written by Rachel Martin <rachel@betterbird.eu>, as a part of Betterbird.
Is this correct? The upstream patch said "Betterbird <betterbird@betterbird.eu>".
Comment 112•3 years ago
|
||
That page has
as in <p>nbsp between number and unit: 5 km.</p>
. The patch is about 0xA0. Anyway, copying this from Chrome and looking at the clipboard in FreeClipViewer (on Windows), it appears that spaces are placed on the clipboard, even for the single NBSPs in « quote ! »
. Can you clarify comment #98 which seems to suggest that not replacing NBSP with space could be a good thing.
As for the attribution, anything goes ;-) - https://hg.mozilla.org/comm-central/log?rev=betterbird
(In reply to Rachel Martin from comment #112)
That page has
as in<p>nbsp between number and unit: 5 km.</p>
. The patch is about 0xA0.
They are the same thing in the DOM.
Can you clarify comment #98 which seems to suggest that not replacing NBSP with space could be a good thing.
I think it could be a good thing, but it's also bad to make stuff up relative to other engines. Earlier comments suggested that Chrome was already doing what was being requested here, in which case it would generally make sense to match. Now it seems that Chrome is not, in fact, already doing what's being requested here. Has Chrome changed between https://bugs.chromium.org/p/chromium/issues/detail?id=887511 and now? If Chrome has made the opposite change, it would be useful to understand why.
Introducing a novel (among engines) behavior may still be a good thing but requires more careful consideration.
As for the attribution, anything goes ;-) - https://hg.mozilla.org/comm-central/log?rev=betterbird
OK.
Comment 114•3 years ago
|
||
Hmm, https://bugs.chromium.org/p/chromium/issues/detail?id=887511 is a little confusing. Seems like the reporter wanted all NBSP to be changed to normal space. The developer said (cmt 4): "Mark WontFix since Chrome should change U+00A0 to U+0020 when putting into clipboard." Is there the word "not" missing? "Should not change"? They go onto say (cmt 7): "I said from Chrome's point of view putting U+00A0 into clipboard is correct and expected". But yes, Chrome converts NBSP to space, to that issue got "fixed" somehow.
Comment 115•3 years ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #113)
Introducing a novel (among engines) behavior may still be a good thing but requires more careful consideration.
This bug is 16 years old and we're still debating whether it should be implemented or not. Incredible!
When I copy-paste things around, the expectation is that they will arrive unchanged (thus the name "copy"). I also asked around and this is the case with everybody who answered my very unscientific quizz. The reference here is not browsers, but text editors. Does MS Word change non-breaking spaces? Open/LibreOffice? Generic text editors (Notepad, Notepad++, Sublime, vim, emacs etc.) with their default settings?
Comment 116•3 years ago
|
||
(In reply to Rachel Martin from comment #114)
Hmm, https://bugs.chromium.org/p/chromium/issues/detail?id=887511 is a little confusing. Seems like the reporter wanted all NBSP to be changed to normal space. The developer said (cmt 4): "Mark WontFix since Chrome should change U+00A0 to U+0020 when putting into clipboard." Is there the word "not" missing? "Should not change"? They go onto say (cmt 7): "I said from Chrome's point of view putting U+00A0 into clipboard is correct and expected". But yes, Chrome converts NBSP to space, to that issue got "fixed" somehow.
I have just tried in Google Chrome 100.0.4896.60, it does not damage the content of the text areas when selected in the sample form.
Assignee | ||
Comment 117•3 years ago
|
||
What exactly do Chrome and Safari do? I tried copying from https://hsivonen.com/test/moz/nbsp.html in Chrome and pasting into gedit on Ubuntu, Notepad on Windows, and TextEdit on Mac. I also copied from Safari and pasted into TextEdit.
AFAICT, in all four cases all no-break spaces got replaced by regular spaces. What am I missing?
It seems that current versions of Chrome and Safari:
- preserve nbsps when copying from a user-editable area (such as a <textarea>),
- but convert nbsps to spaces not when copying from non-editable text.
As far as I understand, this bug is about user-editable content. In any case, the behavior this patch is trying to implement is just for user-editable content. I'm updating the patch's test to use a textarea, which better reflects the intended behavior.
Now there's the question of why Chrome and Safari replace nbsps when copying non-editable text, and whether Firefox should do the same…
Comment 118•3 years ago
|
||
(In reply to Strainu from comment #115)
When I copy-paste things around, the expectation is that they will arrive unchanged (thus the name "copy"). I also asked around and this is the case with everybody who answered my very unscientific quizz. The reference here is not browsers, but text editors. Does MS Word change non-breaking spaces? Open/LibreOffice? Generic text editors (Notepad, Notepad++, Sublime, vim, emacs etc.) with their default settings?
Text editors do not collapse white space at all. Word processors collapse white space at the end of line only.
Comment 119•3 years ago
|
||
(In reply to Pierre de La Morinerie from comment #117)
Now there's the question of why Chrome and Safari replace nbsps when copying non-editable text, and whether Firefox should do the same…
The most probable answer is they want to be Firefox-compatible ;-)
Comment 120•3 years ago
|
||
(In reply to Pierre de La Morinerie from comment #117)
As far as I understand, this bug is about user-editable content.
A text area is not user-editable content, it is a plain text input control.
Comment 121•3 years ago
|
||
(In reply to Pierre de La Morinerie from comment #117)
As far as I understand, this bug is about user-editable content. In any case, the behavior this patch is trying to implement is just for user-editable content. I'm updating the patch's test to use a textarea, which better reflects the intended behavior.
Please do not limit the scope to user-editable content.
Given {
- a non-editable web page,
- an editable web page,
- a textarea control,
- a readonly textarea control,
- an input control,
- a readonly input control
} containing text where non-breaking spaces are used in the intended way (between a number and its unit, or around French punctuation, or between groups of digits in a single number, etc),
when such text is copied,
then the non-breaking spaces should be preserved,
so that proper formatting propagates to whatever document the user is pasting into.
Given any of the above, where non-breaking spaces are misguidedly used to prevent space collapsing,
when such text is copied,
then non-breaking spaces should be converted to spaces,
so that pasting such text into a plain text document yields multiple spaces.
Comment 122•3 years ago
|
||
It should be noted that French punctuation is different from French spacing; the latter is an example of an inappropriate use of non-breaking spaces.
Assignee | ||
Comment 123•3 years ago
|
||
(In reply to Rachel Martin from comment #114)
Hmm, https://bugs.chromium.org/p/chromium/issues/detail?id=887511 is a little confusing. Seems like the reporter wanted all NBSP to be changed to normal space. The developer said (cmt 4): "Mark WontFix since Chrome should change U+00A0 to U+0020 when putting into clipboard." Is there the word "not" missing? "Should not change"? They go onto say (cmt 7): "I said from Chrome's point of view putting U+00A0 into clipboard is correct and expected". But yes, Chrome converts NBSP to space, to that issue got "fixed" somehow.
For what is worth, I just tested older builds of Chrome on macOS (dating back to 2016), and all nbsps in non-user-editable content already were converted into spaces on copy.
Which means that on macOS at least, Chrome had its behavior to convert non-editable nbsps to spaces for a while (it didn't revert back from an older decision).
(I wonder if this behavior was different on Chrome Linux; if someone with a Linux box can check, that'd be great.)
Comment 124•3 years ago
|
||
Google Chrome 100.0.4896.60
cmt 7
document .getSelection () .toString () .charCodeAt (03)
160
// pasted
'cmt 7' .charCodeAt (03)
32
:-(
Comment 125•3 years ago
|
||
In the last company I worked we wrote web applications to work with documents. And we were heavily copy-pasting text between Word/LibreOffice and the browser. Firefox always has converted non-breaking-spaces to normal spaces, so we all needed to switch to Chrome. There was no other possibility because of this issue. See also my comment from 3 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=359303#c79
In my opinion nothing should be done when copying text from the browser. Just let it be the way it intentionally was put on the website.
Comment 126•3 years ago
|
||
(In reply to N. Göddel from comment #125)
In my opinion nothing should be done when copying text from the browser. Just let it be the way it intentionally was put on the website.
The problem is about copying text from the browser but the reason for the problem is copying text from the mail reader which is caused by a systematic abuse of logic in the mail composer (which is a part of the Mozilla suite).
Comment 127•3 years ago
|
||
Assignee | ||
Comment 128•3 years ago
|
||
(In reply to Yuri Khan from comment #121)
(In reply to Pierre de La Morinerie from comment #117)
Please do not limit the scope to user-editable content.
Thanks for the detailed spec. This is what the attached patch currently implements: in all content (editable or not), intended non-breaking spaces are preserved, and editor-generated non-breaking spaces are replaced.
However the concern here is that Webkit/Blink browsers implement a different behavior, where in non-editable content, all non-breaking spaces are replaced. The question is whether Firefox should implement what you describe (which is a arguably a more correct behavior), or try to stick to the behavior or Webkit/Blink.
Comment 129•3 years ago
|
||
All intended non-breaking spaces should be preserved, whatever the context. What's the reason for the behavior of Webkit/Blink browsers?
Comment 130•3 years ago
|
||
(In reply to Vincent Lefevre from comment #129)
All intended non-breaking spaces should be preserved, whatever the context. What's the reason for the behavior of Webkit/Blink browsers?
The reason is presumably compatibility with Gecko.
Comment 131•3 years ago
|
||
Does anybody know what other parts of the Firefox change U+00A0 NO-BREAK SPACE into U+0020 SPACE or vice versa? I ask because for years I've been compiling Firefox with a patch, linked at the top of this bug, which is a more obvious and more complete fix to this bug than the one under discussion, but even with that, I still can't use U+00A0 NO-BREAK SPACE with Firefox in many contexts, e.g., in Twitter. So even if this patch is accepted in one form or another, it still won't make it possible to tweet U+00A0 using Firefox because there are still other U+00A0 manglers lurking in the code. Does anyone know where they might be, if a bug about them is already opened, and how they might be fixed?
(Sorry if I'm hijacking this bug's discussion to mention other nbsp-related bugs, but I think it's part of the confusion that there are actually several of them and that even fixing this one will leave a lot of problems with nbsp.)
Comment 132•3 years ago
|
||
Twitter is known to change the text entered by the user, so that this may not be a good example (Twitter itself may be the culprit). You need to provide a simple testcase.
Comment 133•3 years ago
|
||
(In reply to David A. Madore from comment #131)
I still can't use U+00A0 NO-BREAK SPACE with Firefox in many contexts, e.g., in Twitter. So even if this patch is accepted in one form or another, it still won't make it possible to tweet U+00A0 using Firefox because there are still other U+00A0 manglers lurking in the code. Does anyone know where they might be, if a bug about them is already opened, and how they might be fixed?
(Sorry if I'm hijacking this bug's discussion to mention other nbsp-related bugs, but I think it's part of the confusion that there are actually several of them and that even fixing this one will leave a lot of problems with nbsp.)
Firefox has a command Report a problem with this page, please use that one to report the problem with Twitter. Note, however, that it need not be the browser’s fault. Facebook, for example, does not allow non-breaking spaces in any browser, which forces you to use ‘_’ instead, which gets you a ban on some groups with strict moderation. I know, this is crazy, but so is the world 🙁
Comment 134•3 years ago
|
||
In the early days of HTML WYSIWYG editing, the only way to encode multiple space characters was to replace all but one of the SP = U+0020 codes that the user had entered with NBSP codes. That was of course an ugly hack, as it had nothing to do with the actual purpose of NBSP = U+00A0, which is to be a "no-break space", not an "additional space".
The problem should have gone away when CSS gave us the 'white-space' property, where you can now select for each HTML element whether multiple SP codes are collapsed into one single visible space during rendering or not: https://www.w3.org/TR/CSS2/text.html#white-space-prop
Unfortunately, by the time that CSS-based solution became available, browsers and their built-in HTML editors were already riddled with various ugly hacks to convert between SP and NBSP codes. I doubt that adding yet ever more such HACKs will get us closer to the actual solution. I suspect the actual solution is to remove any automated conversions between NBSP and SP from all browsers and HTML editors, and to instead fix all the places that originally had motivated these hacks (WYSIWYG HTML editors that support the ability to type multiple spaces in a row) by using instead the CSS 'white-space' property where visual support for multiple spaces is desired.
Comment 135•3 years ago
|
||
(In reply to David A. Madore from comment #131)
... there are still other U+00A0 manglers lurking in the code ...
Please turn to bug 532712. All the mangling happens in WSRunObject.cpp, search for u" "_ns
. For our mail client we've implemented Ctrl+Shift+Space here (something that was rejected by Mozilla in bug 894919) and hacked the Mozilla editor not to remove those spaces straight away. Users can now write e-mail and add NBSP around the French quotation marks, etc.
Comment 136•3 years ago
|
||
(In reply to Markus Kuhn from comment #134)
I doubt that adding yet ever more such HACKs will get us closer to the actual solution.
The proposed change does not add more hacks, it makes an existing hack less obnoxious. I understand your holy rage but this bug has been sitting here for sixteen years now, rendering Firefox useless as a desktop document reader. Please let us do something about it instead of preserving the status quo for the next sixteen years.
(In reply to Christopher Yeleighton from comment #119)
(In reply to Pierre de La Morinerie from comment #117)
Now there's the question of why Chrome and Safari replace nbsps when copying non-editable text, and whether Firefox should do the same…
The most probable answer is they want to be Firefox-compatible ;-)
That's indeed a possible explanation.
AFAICT, both Gecko and Blink export no-break spaces to the clipboard in the HTML flavor. Both Gecko and Blink replace no-break spaces with regular spaces when converting HTML into the plain-text clipboard flavor. When copying from a plain-text context (textarea), Gecko replaces no-break spaces with regular ones but Blink does not.
I suspect the actual solution is to remove any automated conversions between NBSP and SP from all browsers and HTML editors, and to instead fix all the places that originally had motivated these hacks (WYSIWYG HTML editors that support the ability to type multiple spaces in a row) by using instead the CSS 'white-space' property where visual support for multiple spaces is desired.
Ideally, yes. However, doing so carries even more compatibility risk than what's being proposed here.
As a user I see the patch here as something I'd like to see landed. As a reviewer, I think it's appropriate to discuss this in standardization context to avoid making stuff up in an area that potentially interop-sensitive even if less so than many other things.
Comment 138•3 years ago
|
||
Note that under Linux, it is generally possible to paste the selection directly with the middle button, i.e. without using the clipboard. I'm wondering whether the behavior concerning spaces is similar to copy-paste via the clipboard.
Comment 139•3 years ago
|
||
Linux does not offer a clipboard at all. Linux users usually connect to a display server (which need not run under Linux at all). The most popular display server is X Windows, which is based on the X Terminal (X meaning ‘cross’). The X Terminal does not offer a clipboard either; instead, you can paste from either the application-owned primary selection, which is more instantaneous, or the display-owned cut buffer, which is more persistent. Both pastes give the same wrong result.
Comment 140•3 years ago
|
||
(In reply to Christopher Yeleighton from comment #139)
That was overkill and some of it is misleading at best.
- Unless you've got a citation, "X" doesn't mean "cross"... it was named similarly to how the B programming language begat C which begat C++ and D. Originally, there was an operating system named V which had a windowing system named W. When they ported W to UNIX, they named the port X.
- People generally refer to X Windows as X11. It's both shorter and more precise, since previous versions like X10 did exist. (For example, "X11" is the form used in Firefox User-Agent strings as
Mozilla/5.0 (X11; Linux; ...
) - If we're sticking to maximum relevance, "I'm talking about Firefox on X11. Firefox gives the wrong result whether using the
PRIMARY
selection or theCLIPBOARD
selection." was all you needed to say. - It's unarguable that X11 does offer a clipboard, in that the three selections are named
PRIMARY
,SECONDARY
, andCLIPBOARD
and covered by the XDG Clipboards Spec.
As the spec puts it:
X has a thing called "selections" which are just clipboards, essentially (implemented with an asynchronous protocol so you don't actually copy data to them). There are three standard selections defined in the ICCCM: PRIMARY, SECONDARY, and CLIPBOARD.
As for cut buffers, JWZ's X Selections, Cut Buffers, and Kill Rings. has more, but the gist is that they're a hold-over from X10 that were retained for compatibility, nobody should be using them, and nobody probably is, given that Qt and emacs, which were already using selections, switched from only using PRIMARY
to Windows-style handling of PRIMARY
vs. SELECTION
way back around the release of Qt 3.
Also, there was such demand to preserve X11-style "PRIMARY
is selecting and middle-click, CLIPBOARD
is Ctrl+X/C/V" behaviour that Wayland also has both a "primary" clipboard and a "clipboard" clipboard, and utilities like wl-clipboard can manipulate both, though I don't know what the low-level API constants are as that section of The Wayland Book is still a blank TODO.
Comment 141•3 years ago
|
||
(In reply to Stephan Sokolow from comment #140)
Ugh. I brought up Wayland, but forgot to make the point it was intended to support. Namely, that both of the graphical APIs Firefox on Linux can be built against (X11 and Wayland) support a PRIMARY/CLIPBOARD distinction. Therefore, it's only relevant to mention that "Linux" doesn't provide the clipboard services if you think/suspect X11 and Wayland builds may be exhibiting different behaviour.
Assignee | ||
Comment 142•3 years ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #137)
Henri, thanks for your clarifications, and for opening an issue against the spec.
Until the spec issues are sorted out, I have a smaller patch to suggest. Here's the current behavior of Webkit/Blink, when copying from:
- a plain-text control (textarea, input): preserves NBSPs ✅
- a contenteditable node: replaces NBSPs ❌
- a non-editable node: replaces NBSPs ❌
(To be clear, this is the relevant code in Webit/Editor.cpp: when copying from a plain-text control, no replacement happens.)
I suggest, as a minimal beginning, to adopt the same behavior in Firefox. I attached a new single-line patch, that configures copies from text widgets to preserve non-breaking spaces. For all other kind of copies (content editable, or non-editable nodes), the current behavior is preserved.
What do you think?
Updated•3 years ago
|
Assignee | ||
Comment 143•3 years ago
|
||
Henri, any thoughts on this minimal variation of the patch?
Comment 144•3 years ago
|
||
(In reply to Rachel Martin from comment #99)
Implemented the suggestion from the previous comment here:
https://github.com/Betterbird/thunderbird-patches/blob/main/91/bugs/359303-dont-replace-NBSP-m-c.patch
I’ve been testing this patch on my build of Firefox. I have discovered one case where it doesn’t do the right thing: When a line starts with a run of NBSPs followed by a non-space character or end of line, these should be converted to spaces because it’s likely code indentation. In other words, line breaks should be treated as whitespace for the purposes of the heuristic.
(In reply to Pierre de La Morinerie from comment #143)
Henri, any thoughts on this minimal variation of the patch?
Sorry about the delay. I wanted to get some signal from the Web Editing Working Group before replying. I had a change to get this on the WG's meeting agenda today.
Based on that discussion, I think we should proceed with:
- When copying from a plaintext context, such as
textarea
, let's pass all no-break spaces to the clipboard as-is and assume that this behavior is going to stick. - When copying from HTML, keep exporting the HTML clipboard flavor as today.
- When copying from HTML, when a text node has a sequence of no-break spaces that isn't preceded or followed by an ASCII space, don't replace those no-break spaces with ASCII spaces. Assume that this change might need to be reverted if problems arise.
- When JavaScript writes a string to clipboard, we shouldn't touch the no-break spaces.
Assignee | ||
Comment 146•3 years ago
|
||
Sounds great; thanks a lot for carrying this discussion to the relevant working group. The four points above look good to me (especially the distinction between changes that are expected to stick, and those which are more experimental).
The one-line patch currently in review for this bug (https://phabricator.services.mozilla.com/D141934) already implements 1. and 2. – which are the changes expected to stick. I think it would be interesting to land these first, before tackling the more experimental changes (3 and 4). Does that look good to you?
(In reply to Pierre de La Morinerie from comment #146)
Sounds great; thanks a lot for carrying this discussion to the relevant working group. The four points above look good to me (especially the distinction between changes that are expected to stick, and those which are more experimental).
The one-line patch currently in review for this bug (https://phabricator.services.mozilla.com/D141934) already implements 1. and 2. – which are the changes expected to stick. I think it would be interesting to land these first, before tackling the more experimental changes (3 and 4). Does that look good to you?
Looks OK to me, but I'm not familiar with the two-step behavior that's being made use of here, so I requested review also from mbrodesser.
This requires a follow-up bug for points 3-4 mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=359303#c145.
Comment 149•3 years ago
|
||
I wonder if we should not add this to the release notes?
@Sylvestre: the criteria for that are vague (https://wiki.mozilla.org/Release_Management/Release_Notes#How_to_decide_whether_a_change_should_be_included_in_release_notes.3F). Feel free to nominate it.
Comment 151•3 years ago
|
||
Comment 152•3 years ago
|
||
(In reply to Mirko Brodesser (:mbrodesser) from comment #150)
@Sylvestre: the criteria for that are vague (https://wiki.mozilla.org/Release_Management/Release_Notes#How_to_decide_whether_a_change_should_be_included_in_release_notes.3F). Feel free to nominate it.
Include in release notes as a fix for a serious data loss without any work-around (see comment #5)!
Comment 153•3 years ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: A 16 y.o. bug seriously affecting interoperability in non-US culture environments has been fixed.
[Affects Firefox for Android]: Yes
[Suggested wording]: Non-US users will be able to copy numbers published on Web pages because non-breaking spaces used to format them will be preserved.
[Links (documentation, blog post, etc)]: <URL: https://bugzilla.mozilla.org/show_bug.cgi?id=359303#c145 >
Assignee | ||
Comment 154•3 years ago
|
||
Nitpick: this is also relevant to english-speaking users; non-breaking space as a unit separator is definitely a thing in english typography.
Comment 155•3 years ago
|
||
(In reply to Pierre de La Morinerie from comment #154)
Nitpick: this is also relevant to English-speaking users; non-breaking space as a unit separator is definitely a thing in English typography.
This is less important because tools that read physical with units are less common and more likely to accept a space after all.
Comment 156•3 years ago
|
||
(In reply to Pulsebot from comment #151)
Pushed by mbrodesser@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1fca61c97256
preserve nbsps on clipboard export. r=hsivonen,mbrodesser
Note: This change implements 2 requirements out of 4. This bug will be resolved only after all 4 requirements have been implemented.
Assignee | ||
Comment 157•3 years ago
|
||
The remaining requirements were extracted to bug 1769534, so that this bug can be closed.
Comment 158•3 years ago
|
||
bugherder |
Comment 159•3 years ago
|
||
(In reply to Pierre de La Morinerie from comment #157)
The remaining requirements were extracted to bug 1769534, so that this bug can be closed.
Oh, in this case publishing a release note will only cause confusion :-(
Assignee | ||
Comment 160•3 years ago
|
||
I'll try a release notes request with a narrower scope.
Assignee | ||
Comment 161•3 years ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: A 16 y.o. bug about text copied to the clipboard being changed by Firefox has been fixed.
[Affects Firefox for Android]: Yes
[Suggested wording]: Non-breaking spaces are now preserved when copying text from a form control.
[Links (documentation, blog post, etc)]: <URL: https://bugzilla.mozilla.org/show_bug.cgi?id=359303#c145 >
Comment 162•3 years ago
|
||
Note added to 103 nightly notes.
Description
•