532712 - Can't insert non-breaking space (U+00A0) in message composition, and existing nbsp converted into space (0x20) when surrounding characters are altered/deleted - STR: Comment #6

Status: NEW

(Thunderbird :: Message Compose Window, defect, P3)

Description

[Neil Mayhew]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091130 Thunderbird/3.0

Typing Option-Space on Mac generates a non-breaking space (U+00A0). This works in other applications (eg TextEdit). In TB3rc2 on Snow Leopard a regular space is inserted.

However, it works in the Insert HTML dialog, but only if I select the words either side of the break before opening that dialog. I can't insert just the space that way.

I get the same results if I use the Character Viewer (previously known as Character Palette) and click Insert. I can verify what type of space is inserted in several ways, such as by looking at the line breaking.

Reproducible: Always

Steps to Reproduce:
1. Open a new message window
2. Make the window narrow
3. Type words until the line wraps by one word
4. Remove the last space typed, leaving the insertion point between the words
5. Press Option-Space, or open Character Viewer and insert U+00A0
6. Observe line breaking
Actual Results:  
Line breaks before final word

Expected Results:  
Line breaks before second-to-last word

I am using Mac OS 10.6.2. My locale is Canada but the problem also exists with the standard US keyboard.

Comment 2

[Thomas D. (:thomas8)]

Reopening/un-duping after we've just fixed a large chunk of the problem in bug 290565, but unfortunately users still have no direct and reliable way to enter nbsp when composing, which is a major shortcoming given that some locales like French heavily depend on non-breaking spaces (e.g. to keep last word and trailing punctuation together). But there are plenty of usecases in many languages, e.g. users might just want to keep numbers and their units together, or initials and last names etc.
> 100_Euro (where _ =  )
> 100_times faster than...
> Thomas_D.
> J._K.

(In reply to Thomas D. from bug 290565 comment #44)
> At least non-breaking spaces are now getting sent when they are in the
> composition.
> 
> However, getting them into composition is still way too complicated, which
> looks like the main pain point of comment 0:
> - Any direct entry of nbsp into composition fails (alt+255, alt+0160,
> copy/paste using charmap app, Ctrl+Shift+Space not implemented)
> - pasting generally works but not always, e.g. can't paste only nbsp from
> notepad++
> - Insert > HTML:   only works if context words are also inserted, not
> for adding only   at cursor insertion point.
> For this basic everyday task, we can't expect our users to continue using
> workarounds involving copy/paste, Insert > HTML, or Jörg's great
> ThunderHTMLEdit addon
> (https://addons.mozilla.org/en-us/thunderbird/addon/thunderhtmledit/).

Such workarounds are obviously annoying in terms of ux-efficiency, and also violating ux-consistency with other apps out there which just have Ctrl+Shift+Space to enter nbsp. Replacing user-entered data with something else is unwarranted dataloss -> critical.

> So we'll want to open a followup bug for that, which includes implementing
> the default keyboard shortcut for inserting nbsp, Ctrl+Shift+Space. I've
> tried and that part is actually fairly easy (apart from some focus issues),
> but unfortunately in my tests, even editor.insertHTML(" ") fails, so I
> don't know how to add the nbsp to the message source so that it lasts. Any
> ideas welcome.

Comment 3

[Thomas D. (:thomas8)]

This is most likely a bug in Core > Editor, but I'll let others decide which product/component is best.
There's definitely something weird going on which involves word boundaries, internal dom node boundaries, or on-the-fly serializers or some such (sorry I'm not very familiar with these things).

Maybe for someone who knows more than me, the following observation can be helpful:

STR

1) In Windows Notepad, type "#_#" where _ is a nbsp entered with Alt+255.
2) In TB composition, type HelloWorld (without space), then paste #_# from Notepad between Hello and World, so we now have:
> Hello#_#World.
3) Shrink the window of TB composition and insert spaces before "Hello" until it starts to wrap into the next line

Actual result:
#_# has been correctly inserted, nbsp is still present in composition, as seen when the whole phrase "Hello#_#World" wraps into the next line, not just #World.

4) Now, use any known method to delete any one of the hash characters (#) around the non-breaking space, and insert spaces before Hello as needed to force wrapping.

Actual result:
The nbsp is replaced by a regular space (0x20), as seen when World alone wraps into next line

Expected result:
nbsp inserted by user by whichever method must be preserved, and not disappear randomly when surrounding characters are deleted or altered.

Observation:
Non-breaking spaces can only be inserted into composition with at least one leading and trailing other character, and will remain in composition if the sequence remains untouched.
Inserting nbsp alone, or with only one leading, or only one trailing other character fails (same applies for Insert > HTML).
Removing any of the leading or trailing characters inserted with nbsp will replace nbsp with normal space 0x20.

Maybe this observation gives a hint to where the problem is?

Comment 4

[Thomas D. (:thomas8)]

Poor/fragile workaround:

Any indirect method which inserts the non-breaking space together with at least one leading and one trailing other character. Thereafter, never touch that character sequence in any way.

E.g., enter #, alt+255, # in Notepad, then copy/paste "#_#" into TB composition (where _ is nbsp).
Or if you want to get "huhu_!", type and select "huhu!", then Insert > HTML, place cursor before the exclamation mark, press Alt+255, then "Insert" (note that you have to select the words/characters surrounding the intended nbsp for this trick to work!).

Comment 5

[Thomas D. (:thomas8)]

Maybe there's something like DOM-internal text nodes, which come with a trimming function, and node boundaries are wrongly determined instead of morphing foo_bar into a single DOM-internal text node which must not be trimmed? Just speculating...

Comment 6

[Jorg K (CEST = GMT+2)]

Thunderbird users read here:

Please use ThunderHTMLedit 1.7 (attachment 8884657 [details], publication on AMO imminent). It shows clearly were NBSP are.

Just for fun, type |A<space>B| and look at the HTML. Then type |A<space><space>B| and look at the HTML. Lo and behold, you'll see NBSP which the editor added for you, since if it hadn't, the second space would have been collapsed. Now delete the second space and see what happens.

So what I'm trying to say is that NBSP are handled a lot by the M-C Core::Editor and users never think of it.

I'm not sure how reasonable the expected result "and not disappear randomly when surrounding characters are deleted or altered" really is since the editor does remove NBSP when it deems fit.

BTW, I can reproduce your test easily:
Enter |A# #B|. In ThunderHTMLedit replace the space by a &#xA0; or &nbsp; Then delete the two #'s in the "normal view" and check the HTML again. The NBSP is gone.

Firefox users read here:

Do this on http://www-archive.mozilla.org/editor/midasdemo/:
Enter |A# #B|. In the HTML view replace the space by a &#xA0; or &nbsp; Then delete the two #'s in the "normal view" and check the HTML again. The NBSP is gone.

Comment 7

[Thomas D. (:thomas8)]

Followup note: When we have succeded to find any way of directly inserting a nbsp which survives alteration of surrounding characters, Thunderbird will want to implement a cmd_insertNbsp with shortcut key Ctrl+Shift+Space (with key=" ", VK_SPACE did not work in my tests), in a followup bug. Mind that cmd_insertNbsp must only be enabled when focus is in text input fields where we want and are able to accept that input.

Comment 8

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+2) from comment #6)
> Thunderbird users read here:
> 
> Please use ThunderHTMLedit 1.7 (attachment 8884657 [details], publication on
> AMO imminent). It shows clearly were NBSP are.

Thanks for that valuable information.
 
> I'm not sure how reasonable the expected result "and not disappear randomly
> when surrounding characters are deleted or altered" really is since the
> editor does remove NBSP when it deems fit.

I'm sure the expected result is very reasonable, but we we need to try against all odds and find someone who is able to fix this in editor, or to convince TB council to offer Jörg a bigger contract so that he can use his excellent skills and energies to fix this for TB... ;)

N.B. Whiteboard entries traditionally come with brackets, has that syntax changed?

Comment 9

[Jorg K (CEST = GMT+2)]

Editor bugs get some attention these days from the excellent Japanese team around Masayuki, Makoto and others and of course Aryeh. One reason for fixing those bugs is compatibility with Chrome.

That said, using NBSP in web forms is not so common, so I'd imagine that this bug won't have a high priority for FF. In my seven years of TB usage I've never thought about NBSP, so I'm really surprised this is such an issue. However, I can see that for example "Le Monde" (http://www.lemonde.fr/) is using NBSP after/before the French quote characters « »: « La perte de Mossoul est un coup majeur porté au projet de construction d’un Etat islamique »

Comment 10

[Thomas D. (:thomas8)]

This looks to me like the *TESTS* for HTML editor's behaviour wrt nbsp...
So here's where "as Editor deems fit" space handling is mirrored...
Maybe this can assist to understand and locate the actual behaviour in editor's code.

https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/editing/include/implementation.js#5204-5475

*** Behaviour definitions...

https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/editing/include/implementation.js#5204
> function canonicalSpaceSequence(n, nonBreakingStart, nonBreakingEnd) {
>     // "If n is zero, return the empty string."
> ...

https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/editing/include/implementation.js#5265
> function canonicalizeWhitespace(node, offset, fixCollapsedSpace) {
>     if (fixCollapsedSpace === undefined) {
>         // "an optional boolean argument fix collapsed space that defaults to
>         // true"
>         fixCollapsedSpace = true;
>     }
> ...


*** ...and consumers:

https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/editing/include/implementation.js#6191
> ///// The delete command /////
> //@{
> commands["delete"] = {

https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/editing/include/implementation.js#7829
> ///// The insertText command /////
> //@{
> commands.inserttext = {
> ...
> // "Canonicalize whitespace at (node, offset)."
>        canonicalizeWhitespace(node, offset);

Comment 11

[Bruno Pagani]

@JorgK: Yes, this is a big issue from french users (at least the one that respect typography rules). We must use a nbsp inside quotes (« like this ») and before colon (like this : but normal space after). They are maybe some other cases, but none jumps out of my head right now.

That being said, people using sane keyboard dispositions (mainly BÉPO, the french Dvorak version, but also Linux or even MacOS AZERTY) have a way to insert nbsp easily (Maj+Space for BÉPO, not sure about the others).

So we don’t need a shortcut for that, this is not the responsibility of the compositing software I think. But respecting the input characters is OTOH. I’m not sure of the status here after you’ve fixed #290565, I’m waiting for 52.3 which I suppose will include your fix?

Comment 12

[Jorg K (CEST = GMT+2)]

I don't know the status here either. I fixed bug 290565, so NBSP will no longer get lost. TB 52.3 will include that fix. I also changed my add-on ThunderHTMLedit so you can see NBSP in the composition better.

Comment 13

[Thomas D. (:thomas8)]

I think the status here is exactly in described in the STR and actual results of either of comment 0, comment 3, comment 6.
I.e. most directly entered single non-breaking spaces can easily disappear when editing surrounding text; but when they survive in the HTML editor (using tricks as described, e.g. pasting with surrounding characters), they'll also get sent.

The (FF) editor team should look into this.
Along the lines of my comment 10, we need to fully understand the current behaviour first, and the underlying purpose, then try to find something better.

The problem is that in HTML editor, multiple regular spaces do not create any distance between words, because they'll be ignored when parsing HTML. But in email messages, we need the behaviour of a word processor where spacing actually creates distance. That's achieved by converting a sequence of n regular spaces into something like n-1 nbsps and one regular space, so that the nbsps get rendered in HTML to create the distance, and the last space ensures we're not hard-linking words which the user never linked. Then there's an algorithm which in case you decide to delete your distance-creating whitespace, editor is trying to undo/maintain its own conversion by actively managing spaces, e.g. if you delete the last space after the sequence of auto-inserted nbsps, it'll delete the last nbsp instead and preserve the normal space. I guess that also happens in the single-nbsp case, where it's wrongly assumed that deleting the character after the nbsp must effect that that nbsp gets converted into a normal space which breaks (wrongly assuming that any nbsp has been auto-inserted by entering normal spaces). The surprising part is that apparently it's not checked if the deleted character is a normal space, and also just entering only one nbsp is immediately converted into a normal space (which is wrong and probably not required for the other tricks to work). I think something like that happens. Don't take my word for it. We need to analyse.

First step would be to find out where that automagical conversion actually happens in code.

Comment 14

[Thomas D. (:thomas8)]

So from my layman's pov, if I understand this behaviour correctly (of which I'm not sure), these might be the required changes in the space management code:

1) A single nbsp entered by user must not be converted to 0x20 if preceded by a non-whitespace character (and we must ensure that this also works for rtl languages). Would that be a sufficient condition?
2) When deleting the character which follows a single nbsp, only if that character is a space, the nbsp must be deleted. If it's any other following character which gets deleted, don't delete the nbsp.
3) There might be more.

Comment 15

[Bruno Pagani]

Or, as mentioned by someone else, just remove this ugly hack altogether. ;) nbsp are not meant for layout. People should either do plain/text, which is what 99 % of human sent emails require and don’t have such issues or fully embrace HTML and do the actual spacing with CSS.

Comment 16

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #14)
> So from my layman's pov, if I understand this behaviour correctly (of which
> I'm not sure), these might be the required changes in the space management
> code:
> 
> 1) A single nbsp entered by user must not be converted to 0x20 if preceded
> by a non-whitespace character (and we must ensure that this also works for
> rtl languages). Would that be a sufficient condition?
> 2) When deleting the character which follows a single nbsp, only if that
> character is a space, the nbsp must be deleted. If it's any other following
> character which gets deleted, don't delete the nbsp.
> 3) There might be more.

/deleted/substituted by regular space/

Jörg, does that sound like a viable plan to adjust the existing space management without removing it?
Could you find the spot in code where that space management is done? See comment 10.

Comment 17

[Jorg K (CEST = GMT+2)]

I did my investigation as per comment #6 and even updated my add-on ThunderHTMLedit to make the NBSP easily visible. Sadly I really don't have any time locating and fixing the code in Core::Editor.

Comment 19

[Rachel Martin]

https://github.com/Betterbird/thunderbird-patches/blob/main/91/bugs/532712-insert-NBSP.patch
Partial solution to add a NBSP with Ctrl+Shift+Space. Working well in a plaintext composition; in a HTML composition the next character typed replaces the just inserted NBSP with a regular space again, which is the second part of the bug ("existing nbsp converted into space (0x20) when surrounding characters are altered/deleted"). Ctrl+Shift+Space works OK to insert a character between two others. A full fix will require Core::Editor changes.

Comment 20

[Rachel Martin]

As has been discussed in bug 359303 (for example bug 359303 comment #72) French typography mandates a space after the opening quote « and a space before the closing quote », and also in front of an exclamation mark, so for example « Bonsoir ! ». In order to prevent unwanted line wrapping, NBSP needs to be used. French-speaking/writing Mozilla users have struggled for a long time with the fact that all Mozilla editing in FF and TB removes NBSP even if the user manages to enter them via a special key sequence or via pasting. Henri makes the case to improve the situation in bug 359303 comment #98.

We've implemented a Ctrl+Shift+Space function for Thunderbird, see here and the processing is much simpler if the Mozilla editor doesn't replace NBSP with ASCII space, which we've hacked into place here for ESR 91. That removes these two blocks:
https://searchfox.org/mozilla-central/rev/9ca193b4233957439583f2eadabbd3cfb4cd9fed/editor/libeditor/WSRunObject.cpp#1046-1052
https://searchfox.org/mozilla-central/rev/9ca193b4233957439583f2eadabbd3cfb4cd9fed/editor/libeditor/WSRunObject.cpp#3120-3132.
Curiously enough, only removing one of the blocks didn't have the desired effect. Removing the two blocks has the side effect that a x\u00a0 y test is not corrected to x y any more if the second space is removed.

Masakuyi-san, what is the motivation to replace NBSP with ASCII space? The comments suggest that this is done "just to prevent NBSP proliferation" which is not a very good reason to make the life of French speakers hard. Another reason mentioned is Blink compatibility, but that doesn't see to be switched on so far (and the second code block will still remove NBSP between visible characters which is not necessarily desirable).

Can the editor be changed to allow entering of NBSP more easily?

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Masakuyi-san, what is the motivation to replace NBSP with ASCII space?

One big reason of doing it is, editor cannot remember whether each NBSP is inserted as-is or converted from a collapsible white-space. If the latter, doing it is the right thing. However, if the former, yes, it's this bug.

The comments suggest that this is done "just to prevent NBSP proliferation" which is not a very good reason to make the life of French speakers hard. Another reason mentioned is Blink compatibility, but that doesn't see to be switched on so far (and the second code block will still remove NBSP between visible characters which is not necessarily desirable).

One possible solution for Thunderbird which I think is, if the editor is a mail editor, set white-space: pre-line to the <body> and stop the white-space normalization. However, (although I'm not sure) Thunderbird could need to remove the style and do normalizing white-spaces before sending the email because some legacy MUA may not support the style.

Comment 22

[Rachel Martin]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #21)

One big reason of doing it is, editor cannot remember whether each NBSP is inserted as-is or converted from a collapsible white-space. If the latter, doing it is the right thing. However, if the former, yes, it's this bug.

Understood. However, the conversion could be a lot less aggressive, for example, insertText("\u00a0") should not immediately insert an ASCII space, and typing the B of A\u00a0B should also not trigger the replacement, even removing the B on «\u00a0B shouldn't trigger the replacement. Clean-up of NBSP which was auto-inserted from collapsible white-space should only be done when cleaning up longer stretches of white-space where NBSP is adjacent to regular ASCII space, which is also the suggested solution for bug 359303.

Is this not also an issue for Webmail in Firefox?

Comment 23

[Rachel Martin]

During testing we also noted the following: Starting from A B and removing the B via backspace, there appears to be an intermediate state of A\u00a0. That makes the removal of the NBSP necessary when the next character is typed. And exactly that logic also replaces manually inserted NBSP. For the purposes of the mail client we've hacked this now, but given that this is registered as a Core::Editor bug we'd like to suggest to maybe revise the algorithm: If less NBSP are created automatically, less need to be removed later which reduces the scope of also removing user-entered ones.

Comment 24

[u704657]

I confirm NBSPs are still automatically converted to regular spaces in message composition and other fields such as calendar event fields… and on copying and pasting text.

Comment 25

[Christopher Yeleighton]

Reiterating, since some developers still seem to misrepresent the problem: the editor software MUST NOT insert non-breaking spaces at will. Normalisation of white space is a feature of HTML itself and the HTML editor has no business in messing around with that. That means sequences of consecutive spaces should be collapsed on input. This unfortunately means no French spacing for me; I understand that French spacing is a feature of the renderer and should not be hardwired into the text. I also understand that the rendering engine does not currently provide such an option to me, which is deplorable but by no means as toxic and debilitating as this bug and the accompanying ones.
The only reliable way to have consecutive, initial or trailing spaces in HTML is to put them into a text control. This has been a recurring source of misunderstandings, drama and waste of time in browser-facing database applications since the Bing Bang. We should offer another document format for editors who cannot put up with this.
OTOH, the editor software MAY automatically use non-breaking space in a locale-specific way where appropriate, as an opt-in feature. This includes hyphenation aids too.

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Probably, this has already been fixed in bug 1724650 from point of view of Core product. The remaining issue is probably that mail composer does not specify white-space: pre-wrap to the body. However, I'm not sure whether the style is available in any major mail-apps. Therefore, it's out of scope of this bug that whether specifying the style and exposes it as-is or converting only collapsible white-spaces to NBSPs or not at sending email it. I'll add automated tests for avoiding regressions in the Core product.

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Try: https://treeherder.mozilla.org/jobs?repo=try&revision=44ab3b452e83306b112f918258321271b055e390

Comment 28

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Away: ~5/8) from comment #21)

One possible solution for Thunderbird which I think is, if the editor is a mail editor, set white-space: pre-line to the <body> and stop the white-space normalization.

Oh, s/pre-line/pre-wrap

(In reply to Rachel Martin from comment #22)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #21)

One big reason of doing it is, editor cannot remember whether each NBSP is inserted as-is or converted from a collapsible white-space. If the latter, doing it is the right thing. However, if the former, yes, it's this bug.

Understood. However, the conversion could be a lot less aggressive, for example, insertText("\u00a0") should not immediately insert an ASCII space, and typing the B of A\u00a0B should also not trigger the replacement, even removing the B on «\u00a0B shouldn't trigger the replacement. Clean-up of NBSP which was auto-inserted from collapsible white-space should only be done when cleaning up longer stretches of white-space where NBSP is adjacent to regular ASCII space, which is also the suggested solution for bug 359303.

Is this not also an issue for Webmail in Firefox?

Could be. However, basically, web-apps should use white-space: pre-wrap and convert it at sending email if they need some conversion for compatibility with the other MUAs. For web-compat, we should emulate Blink's white-space normalizer as far as possible (bug 1658699). However, it's big project and currently there are no serious bug reports about this difference. So we won't fix it soon.

Comment 29

[Rachel Martin]

This bug was originally filed in Thunderbird/Message Compose Window and was moved to Core/Editor after comment #6. If the NBSP issue is now fixed for white-space: pre-wrap, this will still not give Thunderbird users what they need since TB so far doesn't use white-space: pre-wrap and it would need some investigation as to whether it can use that. So it's probably best to move the bug back to Thunderbird and land your tests in a new bug specifically for white-space: pre-wrap.

To address mail users' needs, we have added two things to our mail client:
At comm level, a command that adds NBSP: https://github.com/Betterbird/thunderbird-patches/blob/main/102/bugs/532712-insert-NBSP.patch
At Mozilla level, a nasty hack that ensures the added NBSP isn't removed again when the next character is typed:
https://github.com/Betterbird/thunderbird-patches/blob/main/102/bugs/532712-insert-NBSP-m-c.patch
That's not ideal, it only maintains the NBSP if you type A 0xa0 B, but not A 0xa0 B <del> C. But better than nothing.

Comment 30

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 532712 - Add automated tests of white-space conversions in the mail editor mode r=m_kato!

Probably, the editor's bug has already been fixed in bug 1724650 which makes
HTMLEditor and WhiteSpaceVisibilityKeeper handle white-spaces of
white-space: pre-* correctly. Therefore, once Thunderbird or some other
MUAs which uses Gecko as its mail composer specify white-space: pre-wrap,
at least the editor will work as users expected.

This patch just adds automated tests for avoiding the regressions in Gecko-side.

Comment 31

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sure. Once I land the test for mozilla-central, I'll make this moved back to Thunderbird. However, it might be better to open new bug because this bug has 30 comments which makes newbies of this bug harder to understand what is the remaining issue.

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b5b19021b756
Add automated tests of white-space conversions in the mail editor mode r=m_kato

Comment 33

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The simplest fix as an application of Thunderbird is, setting white-space: pre-wrap to the <body> element of editor document. However, if it's sent to another MUA's user, the style might be ignored. Although even IE8 supports it, but I guess that there are some MUAs which serialize HTML simply. So, from compatibility between MUAs, it might be safer to remove the style at sending, and replaces collapsible white-spaces when serializing. However, I don't know whether it's worthwhile to do it or not.

On the other hand, in plaintext emails, perhaps, the plaintext serializer would break the NBSPs which are intentionally inserted.

Comment 34

[Rachel Martin]

So leaving NBSP inserted with insertText("\u00a0") alone (instead of replacing it with a normal space on the next key stroke) is not an option for the core editor?

Comment 35

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Rachel Martin from comment #34)

So leaving NBSP inserted with insertText("\u00a0") alone (instead of replacing it with a normal space on the next key stroke) is not an option for the core editor?

Ah, that should be fixed with the compatibility with Chrome. However, replacing around the inserted NBSP is odd even in Chrome. So it requires a lot of time to investigate the behavior, and I guess that that will require to reimplement the white-space normalizer in bug 1658699. So it cannot be a short term solution.

Comment 36

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/b5b19021b756

Comment 37

[Rachel Martin]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Away: ~5/8) from comment #35)

Ah, that should be fixed with the compatibility with Chrome. ...

That makes it sound like this bug still belongs into Core/Editor. It's unlikely that TB will change to white-space: pre-wrap also given that the receiving end might not support it.

Comment 38

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Rachel Martin from comment #37)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Away: ~5/8) from comment #35)

Ah, that should be fixed with the compatibility with Chrome. ...

That makes it sound like this bug still belongs into Core/Editor.

Partially, yes, but it should be fixed in bug 1658699.

It's unlikely that TB will change to white-space: pre-wrap also given that the receiving end might not support it.

So, I recommend that touching the DOM tree before sending, but use white-space: pre-wrap while composing email. Otherwise, anyway NBSPs may be silently converted to collapsible white-spaces when normal white-spaces come next to NBSPs.