Where exactly is this nbsp entered? Anywhere in the text? Which browser is this about?

In T96701#1225129, @Aklapper wrote:

Where exactly is this nbsp entered? Anywhere in the text?

Yes, I enter a non-breaking space anywhere in the text of the article.

In T96701#1225129, @Aklapper wrote:

Which browser is this about?

This bug occurs with Safari Mac and with Firefox Mac, if I remember correctly.

This task and the task T53045 are closely related, but the task T53045 is not required for this one.

The visual editor's feature for inserting a non-breaking space will not remove the need to respect the natively entered non-breaking spaces.

Regarding a way to distinguish a non-breaking space : articles have non-breaking spaces already.

I will edit the task description here to mention the other task.

• This is actually a Parsoid issue: it converts all   in input HTML to regular space in wikitext. I'm not sure why, but it looks intentional.
• This would probably no longer be a problem after T53045, after which pressing Opt+Space in VisualEditor will generate a   (in a format that Parsoid actually preserves).

In T96701#1225154, @Nnemo wrote:

In T96701#1225129, @Aklapper wrote:

Which browser is this about?

This bug occurs with Safari Mac and with Firefox Mac, if I remember correctly.

The bug occurs with Safari iPad too. We may think that the bug occurs with any Web browser.

In T96701#1837191, @matmarex wrote:

This is actually a Parsoid issue: it converts all   in input HTML to regular space in wikitext. I'm not sure why, but it looks intentional.

I think that removing this conversion would be a very good thing. :-)

This would probably no longer be a problem after T53045, after which pressing Opt+Space in VisualEditor will generate a   (in a format that Parsoid actually preserves).

I disagree.

Pressing Option Space would tell the visual editor to insert a non-breaking space, OK.

But the visual editor still would have to respect the non-breaking spaces entered natively.

Pressing Option Space is not the only way to enter a non-breaking space. On Mac, there are other ways (the Character Palette...). On iPad, I enter non-breaking spaces without pressing Option Space. A non-breaking space can be pasted, dragged-and-dropped...

Good news: the visual editor does not have to handle all the cases. He just has to respect the text entered.

Thank you.

Hmm. That might actually be possible now. It was impossible when I wrote that comment, because of T55931 (the editor used to use   internally wherever more than one space in a row was entered), and that's probably the reason why Parsoid filters   out.

I don't believe this is a parsoid issue, but I can see how it would be mistaken for one.

When given a non-breaking space either as   or as a literal \u00A0, Parsoid emits a unicode non-breaking space in the wikitext. This round-trips fine.

If you want parsoid to represent the non-breaking space as literal   in the wikitext, then you need to tell parsoid that, by wrapping the non-breaking space in a span:

<span typeof="mw:Entity">&nbsp;</span>

The mw:Entity typeof tells Parsoid that this wants to be a literal HTML entity in the wikitext, not a literal character. This is exactly the same mechanism used to distinguish &lt; and &gt; and &quot; from < > ", etc, in the literal wikitext.

@cscott Could you please take a look at this: https://en.wikipedia.org/w/index.php?title=Toyota_Land_Cruiser&oldid=prev&diff=720847140

The nbsp was entered in the wikitext editor, in a previous edit. It was removed when an unrelated change was made (on a different line) in the visual editor.

Can you tell me whether the nbsp code was removed by VisualEditor or by Parsoid?

In T96701#2306167, @Whatamidoing-WMF wrote:

@cscott Could you please take a look at this: https://en.wikipedia.org/w/index.php?title=Toyota_Land_Cruiser&oldid=prev&diff=720847140

The nbsp was entered in the wikitext editor, in a previous edit. It was removed when an unrelated change was made (on a different line) in the visual editor.

Can you tell me whether the nbsp code was removed by VisualEditor or by Parsoid?

In that particular case, the &nbsp; is actually in a comment, not in the wikitext itself. It appears to have been converted from an entity to a literal unicode non-breaking space during the round-trip. That looks like a bug (one, it should round-trip; two, selser should prevent an unrelated change from being made) although it is *possible* that the user (unintentionally) made this change. This probably merits a new phab task, if it is reproducible, since this task was about the user manually entering option-space, which is different from "round-tripping &nbsp; embedded in html comments fails".

I've opened T199579 for this particular case.

This ticket contains two different bugs:

1. we can’t add non-breaking space in both VisualEditor and 2017-Wikitext-Editor typing it from advanced keyboard layout (e.g. AltGr+Shift+Space which is common working combination in Linux distributions)
2. VisualEditor removes already inserted non-breaking space (see this diff explained at mw:Topic:Ufdfbz9v6qs9mq9u). I can’t reproduce that with Firefox 60.4 on Debian. It’s probably browser-related. (In the past, Firefox removed nbsp in text inputs).

Change 665132 had a related patch set uploaded (by Bartosz Dziewoński; owner: Esanders):
[VisualEditor/VisualEditor@master] Detect NBSPs being inserted deliberately by IMEs

https://gerrit.wikimedia.org/r/665132

Change 665132 merged by jenkins-bot:

[VisualEditor/VisualEditor@master] Detect NBSPs being inserted deliberately by IMEs

https://gerrit.wikimedia.org/r/665132

Change 676162 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (5d0701ea3)

https://gerrit.wikimedia.org/r/676162

Change 676162 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (5d0701ea3)

https://gerrit.wikimedia.org/r/676162

This should be resolved now. We'd appreciate if you could test with your favorite operating system / browser / language / keyboard layout / input method, as it's impossible for us to verify all combinations. The fix is deployed now on https://en.wikipedia.beta.wmflabs.org/ and should be deployed to production wikis next week.

In T96701#6965677, @matmarex wrote:

This should be resolved now. We'd appreciate if you could test with your favorite operating system / browser / language / keyboard layout / input method, as it's impossible for us to verify all combinations. The fix is deployed now on https://en.wikipedia.beta.wmflabs.org/ and should be deployed to production wikis next week.

Tested this with Safari and Chrome on Mac. Seems resolved to me.

I don’t know whether it is expected, but I find the current behavior strange: VisualEditor inserts &nbsp HTML entity instead of real U+00A0 character (example).

Why not keeping plain char, as 2010 wikitext editor does? (example)

Because the popular wikEd tool on en.wp replaces the real characters with HTML entities, and then people blame us for it (see T183647).

Even if that bug didn't exist, I think that using the entity is preferable, to allow people editing in wikitext to see them. https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Non-breaking_spaces also recommends using entities (I'm aware that this is only a rule for English Wikipedia, but it seems like a good one to follow elsewhere as well).

OK, this doesn’t matter.

However, with 2017 Wikitext Editor, inserting a NBSP makes the cursor live the writing surface, which is pretty annoying: I can’t type NBSP as any character because I need to use my mouse to give focus to the surface again after I typed the NBSP. Should I open a new task?

Yes, it's easier to keep track of as a separate task. I filed one for this: T279600. I think we didn't test this change with the wikitext editor :(