VE silently alters non-breaking spaces into normal spaces
Open, LowPublic

Description

On Mac, I edit Wikipedia with the Web visual editor.

I enter a non-breaking space, by pressing Option Space.

The visual editor must simply respect the character entered.

Instead, the visual editor silently alters the non-breaking space into a normal space.
This is incorrect.

This bug has no workaround, as far as I know.

This is the most annoying bug in the visual editor for me.
This bug often makes me give up using the visual editor of Wikipedia.

Thank you for fixing this bug.

Nnemo

See also :

Nnemo created this task.Apr 21 2015, 4:31 PM
Nnemo updated the task description. (Show Details)
Nnemo raised the priority of this task from to Needs Triage.
Nnemo added a subscriber: Nnemo.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 21 2015, 4:31 PM
Aklapper renamed this task from The visual editor silently alters non-breaking spaces into normal spaces to VE silently alters non-breaking spaces into normal spaces.Apr 21 2015, 6:31 PM
Aklapper set Security to None.

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

Nnemo added a comment.EditedApr 21 2015, 7:02 PM

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

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

Which browser is this about?

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

Nnemo added a comment.Apr 23 2015, 4:11 PM

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.

Nnemo updated the task description. (Show Details)Apr 23 2015, 4:13 PM
Neil_P._Quinn_WMF triaged this task as Low priority.May 12 2015, 10:56 PM
Nnemo awarded a token.Aug 2 2015, 6:05 PM
matmarex added a subscriber: matmarex.
  • 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).
Nnemo added a comment.Jan 21 2016, 8:23 PM

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.

Nnemo added a comment.Jan 21 2016, 8:38 PM

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.

cscott added a subscriber: cscott.Jan 21 2016, 9:04 PM

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?

Elitre added a subscriber: Elitre.May 19 2016, 7:58 AM
Dvorapa removed a subscriber: Dvorapa.
cscott added a comment.EditedJul 13 2018, 9:54 PM

@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.