1769534 - Preserve non-breaking spaces when copying HTML content

Status: REOPENED

(Core :: DOM: Serializers, defect, P3)

Description

[Pierre de La Morinerie]

Steps to reproduce:

1. Select some HTML text that contains non-breaking spaces (e.g. https://hsivonen.com/test/moz/nbsp.html);
2. Copy the text (using the menu, context menu, or a keyboard shortcut);
3. Paste the text in an external editor

Actual results:

On copy, Firefox converts the non-breaking spaces to regular spaces.

Expected results:

Non-breaking spaces should be preserved when being copied to the clipboard.

Comment 1

[Pierre de La Morinerie]

Additional context:

This is a follow-up for bug 359303, which was about NBSP being converted to regular spaces when copied from plain-text controls (like textearas). This bug, however, is for copying text from HTML content – which will introduce an arguably more correct, but divergent behavior from what other browsers do.

From the following discussion in the Web Editing Working Group (https://github.com/w3c/clipboard-apis/issues/173#issuecomment-1125130700), the following behavior should be implemented:

1. 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.
2. When JavaScript writes a string to clipboard, we shouldn't touch the no-break spaces.

Comment 2

[Pierre de La Morinerie]

Attachment: Bug 1769534 - preserve NBSP when copying HTML content. r=mbrodesser

To workaround the historical lack of 'white-space: pre', when an user
wants to compose HTML text with several consecutive spaces, WYSIWYG
HTML editors insert an alternating pattern of SPACE and NBSP to avoid
spaces being collapsed.

This is why browsers, when copying HTML content, usually strip all NBSP
from the copied text.

This commit changes the copying behavior, to strip only NBSP that were
generated by an editor (and preserve the others).

The heuristic used is "An NBSP adjacent to a regular space doesn't make
sense, and can be replaced by a regular space". This detects the
alternating pattern of SPACE/NBSP, but also a space followed by a long
sequence of NBSP (because a line break would occur anyway in that case).

Comment 3

[Rachel Martin]

Please add some attribution (see bug 359303 comment #103) to the patch header.

Comment 4

[Pierre de La Morinerie]

Indeed, I forgot to re-add the attribution from the previous patch.

Attribution added, with the following wording: "Attribution: the actual nsPlainTextSerializer changes were written by Rachel Martin <[e-mail]>, as a part of Betterbird."

Comment 5

[Pierre de La Morinerie]

I have an implementation question.

In the devtools, the code for formatting a stacktrace pads the frames with non-breaking spaces. For instance, given the following HTML stacktrace:

console.trace() myConsoleTrace test.js:7:9
    wrapper test.js:7
    logStuff test.js:14

Before this patch, when copying to the clipboard, the   characters would get replaced by regular spaces.
With this patch, the NBSPs are now preserved.

If including those padding NBSPs in the copied text is the new desired behavior, I can fix the test.

However, if the desired behavior would be to keep outputting regular spaces, I see two alternatives:

1. Adjust the algorithm in this patch, to also consider NBSPs near a newline character to be obviously for padding, and replace them by regular spaces when copying to plain-text;
2. Or adjust the devtools code to output regular spaces.

:mbrodesser any thoughts? Or an idea of someone in the devtools team who could have insights on this?

Comment 6

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

(In reply to Pierre de La Morinerie from comment #5)

I have an implementation question.

In the devtools, the code for formatting a stacktrace pads the frames with non-breaking spaces. For instance, given the following HTML stacktrace:

console.trace() myConsoleTrace test.js:7:9
    wrapper test.js:7
    logStuff test.js:14

Before this patch, when copying to the clipboard, the   characters would get replaced by regular spaces.
With this patch, the NBSPs are now preserved.

If including those padding NBSPs in the copied text is the new desired behavior, I can fix the test.

However, if the desired behavior would be to keep outputting regular spaces, I see two alternatives:

1. Adjust the algorithm in this patch, to also consider NBSPs near a newline character to be obviously for padding, and replace them by regular spaces when copying to plain-text;
2. Or adjust the devtools code to output regular spaces.

:mbrodesser any thoughts? Or an idea of someone in the devtools team who could have insights on this?

Both alternatives are interesting. It would be helpful if someone from the DevTools team can explain why NBSPs are inserted in the first place. @Nicolas: do you know or can you please forward the ni?-request to someone who can?

Comment 7

[Nicolas Chevobbe [:nchevobbe]]

This was added in Bug 1486870 in order to have the frames of the stacktrace "indented" when copying them to the clipboard. I don't remember the detail but in my memory it was painful to get it right.
These spaces are not displayed visually by having this clipboard-only class (https://searchfox.org/mozilla-central/rev/3e1a721bce1da3ae04675539b39a4e95b25a046d/devtools/client/debugger/src/components/SecondaryPanes/Frames/FrameIndent.js#9-11)
I would be fine with any change that would preserve the copied output and doesn't impact the layout in the console.
Let me know if you want me to test/check anything

Comment 8

[Yuri Khan]

Quick tinkering with the Browser Toolbox:

1. Find a page with a stacktrace in the console.
2. Open Browser Toolbox with Ctrl+Alt+Shift+I.
3. Copy the stack trace into an editor.

Observed original behavior: the line is visually indented.

4. Inspect the stacktrace’s first indented line.
5. In the Inspector, find the <span class="frame-indent clipboard-only"> node.
6. Change its contents to four spaces.
7. Copy the stack trace into an editor.

Observed intermediate result: the modified line is not indented.

8. In the Rules tab of the Inspector sidebar, modify the .clipboard-only or .frame-indent rule to include white-space: pre.
9. Copy the stack trace into an editor.

Observed result: the modified line is visually indented again, and no longer uses non-breaking spaces against their intended semantics.

Comment 9

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

(In reply to Yuri Khan from comment #8)

Thanks for the feedback.

Quick tinkering with the Browser Toolbox:

1. Find a page with a stacktrace in the console.
2. Open Browser Toolbox with Ctrl+Alt+Shift+I.
3. Copy the stack trace into an editor.

Observed original behavior: the line is visually indented.

4. Inspect the stacktrace’s first indented line.

How does one inspect a stacktrace's line in the sidebar? The corresponding menu item is grayed out on my machine. Any pref to flip here?

5. In the Inspector, find the <span class="frame-indent clipboard-only"> node.
6. Change its contents to four spaces.
7. Copy the stack trace into an editor.

Observed intermediate result: the modified line is not indented.

8. In the Rules tab of the Inspector sidebar, modify the .clipboard-only or .frame-indent rule to include white-space: pre.
9. Copy the stack trace into an editor.

Observed result: the modified line is visually indented again, and no longer uses non-breaking spaces against their intended semantics.

Agree, that style="white-space: pre;" should be used instead of NBSPs at https://searchfox.org/mozilla-central/rev/284187d0a7130d21042beeff0af0627c8e68cacc/devtools/client/debugger/src/components/SecondaryPanes/Frames/FrameIndent.js#10.

@Nicolas: would you accept that change?

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

Sure, I'll gladly accept it

Comment 11

[Yuri Khan]

(In reply to Mirko Brodesser (:mbrodesser) from comment #9)

How does one inspect a stacktrace's line in the sidebar? The corresponding menu item is grayed out on my machine. Any pref to flip here?

Browser Toolbox is documented here. It lets you inspect browser chrome as opposed to page content.

Comment 12

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #10)

Sure, I'll gladly accept it

Thanks.

Pierre: if you want you can update that in the already existing patch. Then we could get this landed soon.

Comment 13

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

(In reply to Yuri Khan from comment #11)

(In reply to Mirko Brodesser (:mbrodesser) from comment #9)

How does one inspect a stacktrace's line in the sidebar? The corresponding menu item is grayed out on my machine. Any pref to flip here?

Browser Toolbox is documented here. It lets you inspect browser chrome as opposed to page content.

Thanks. TIL.

Comment 14

[Pierre de La Morinerie]

Pierre: if you want you can update that in the already existing patch. Then we could get this landed soon.

Sure. I've updated the same patch with a .frames .frame-indent { white-space: pre } rule, and replaced NBSPs by spaces.

Comment 15

[Pierre de La Morinerie]

The patch is still waiting for a final review pass, but the status of :mbrodesser has been "away for an unknown duration" for two months.

Does someone know who else I could reach for a code review?

Comment 16

[Henri Sivonen (:hsivonen)]

I'll take a look. Sorry about not checking how this is going earlier.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a50d707b3bbc
preserve NBSP when copying HTML content. r=hsivonen

Comment 18

[Marian-Vasile Laza]

Backed out changeset a50d707b3bbc (Bug 1769534) for causing debugger frame failures.
Backout link
Push with failures <--> debugger
Failure Log

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:kemenaran, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Comment 20

[Pierre de La Morinerie]

Yes, I'll have a look (a bit busy with real life for now, but I definitely want to investigate and land this patch).

Comment 21

[Henri Sivonen (:hsivonen)]

Relanded. Thanks.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/34c1c9be027d
preserve NBSP when copying HTML content. r=hsivonen

Comment 23

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/34c1c9be027d

Comment 24

[Pierre de La Morinerie]

An interesting edge-case is raised in bug 1794575. When a string beginning with a single space is inserted into an HTML editor (e.g. " AB CD"), the editor (unnecessarily) converts the leading space into an NBSP.

When serializing the string back, the current heuristic implementation receives " AB CD", doesn't see any NBSP adjacent to a space, and keeps the editor-generated NBSP in the output.

The question is : should we also consider a single string-leading NBSP as an editor-generated NBSP, and replace it by a regular space? (Or is it potentially risking a false positive, and replacing an user-generated NBSP by a space?)

Comment 25

[Rares Doghi, Desktop QA]

Hi Pierre, I tried to verify the fix on this issue but I dont quite understand how to verify this issue, I copied the text from the https://hsivonen.com/test/moz/nbsp.html page and pasted it into a notepad and I'm always getting the same spaces, I dont see any difference from the older Firefox or the latest one, Ive also tried to copy and paste it from Chrome and im still getting the exact same text with the same spaces between words, Also pasted the text into Microsoft Word and I still got the same result.
I was testing this on a Windows 10 machine, does the issue not occur there ?

How can we check if the non breaking spaces are converted to regular spaces ?

Comment 26

[Pierre de La Morinerie]

I'd say there's two ways of testing this.

First is to use an editor that will somehow display non-breaking spaces as special characters. I think Sublime Text does this by default; otherwise you can also use the "Find…" command of a text editor (like VS Code), put a non-breaking space in the textbox, and see non-breaking space highlighted in the editor.

The other one is to test the actual effect of the non-breaking space. For this, you can for instance copy the first line of https://hsivonen.com/test/moz/nbsp.html (the one with a distance unit) in a text editor. Then resize slowly the text editor window, until there's a line break between the number and the unit. If you can find a window width that places them on two separate lines, there's an (incorrect) regular space between them. But if you can't, and the unit is displayed on the same line than the unit no matter what, then a (correct) non-breaking space is used.
(See this visual example: https://imgur.com/a/xE5vVvF)

Does that answer your question?

Comment 27

[Rares Doghi, Desktop QA]

Thanks a lot @Pierre for the extra info, this helped me verify this Fix ! This issue is verified as fixed in our latest Nightly build 108.0a1 (2022-10-31) and our latest beta 107.0b7.

Comment 28

[Chris Siebenmann]

After this change, copying from indented lines in Hypermail HTML archives of email gives non-breaking spaces instead of spaces. This appears to be because Hypermail indents lines using a sequence of non-breaking spaces only, with no regular spaces, and so this doesn't trigger the 'convert to spaces' heuristics. Perhaps a sufficiently long sequence of non-breaking spaces should be recognized as indentation and converted to spaces, even without a space at the start or the end.

Comment 29

[Pierre de La Morinerie]

Thanks for raising the issue.

I'm worried about adding a length heuristic, because it could create confusion about why some short indented lines have NBSP, and others with longer indentations are using regular spaces.

However, if those are used for indentation, would an heuristic such as “an NBSP adjacent to a line break is considered as being used for indentation and converted to a regular space” work in your case?

Comment 30

[Chris Siebenmann]

That heuristic would definitely work in my case, and it would also deal with the issue of one-space indents, which wouldn't be detected by a 'must be N nbsp long' heuristic. However, I wonder if there are additional cases of nbsp runs being used for interior indentation ('...A...B...C' style, for instance to render an ASCII table). Would it be reasonable to convert two or more nbsps to spaces on cut & paste, or are multiple nbsps used in regular HTML in a context where they should be preserved on paste?

Comment 31

[Jeff Muizelaar [:jrmuizel]]

It seems like this is causing problems for others: https://www.reddit.com/r/firefox/comments/yxmrt9/firefox_is_now_changing_white_space_indents_into/

Comment 32

[Pierre de La Morinerie]

Based on these comments, it seems non-breaking spaces for indenting content (i.e. at the beginning of a line) is pretty common, but doesn't not follow the editor-generated pattern of “an NBSP adjacent to a regular space”.

I guess we should tweak the heuristic into “an NBSP adjacent to a line-break or beginning of line is also considered as a nonsense character, and gets replaced by a space”. I’ll try to have a look soon.

Meanwhile, since some people wonder what is going on, should we add this behavior change to the release notes (even after the release date)?

Comment 33

[Henri Sivonen (:hsivonen)]

Yeah, it looks like there's a need to complicate the heuristic with a start-of-line check to deal with using NBSPs for indent.

Comment 34

[Henri Sivonen (:hsivonen)]

pascalc, see the last paragraph of comment 32. Can we add a relnote item after the release?

Comment 35

[Pascal Chevrel:pascalc (PTO until April 26)]

(In reply to Henri Sivonen (:hsivonen) from comment #34)

pascalc, see the last paragraph of comment 32. Can we add a relnote item after the release?

Yes, we can add a Known Issue. CCing Donal (107 manager).

Henri, Pierre, could you provide the wording? Thanks

Comment 36

[Henri Sivonen (:hsivonen)]

I suggest:

"In order to better support certain typographical conventions, Firefox now preserves some non-breaking spaces (instead of changing them to regular spaces) when copying text to clipboard. The new behavior is known to cause problems when non-breaking spaces are used for indentation."

Comment 37

[Donal Meehan [:dmeehan]]

Known Issue added to the 107 release notes https://www.mozilla.org/firefox/107.0/releasenotes/
I tweaked the wording slightly

Comment 38

[Henri Sivonen (:hsivonen)]

(In reply to Donal Meehan [:dmeehan] from comment #37)

Known Issue added to the 107 release notes https://www.mozilla.org/firefox/107.0/releasenotes/
I tweaked the wording slightly

Thanks.

Let's use bug 1801186 for further discussion of addressing the indent case.

Comment 39

[Ryan VanderMeulen [:RyanVM]]

Backed out for 109.0rc2 for causing bug 1801186.
https://hg.mozilla.org/releases/mozilla-release/rev/997f4574962f

Comment 40

[Ryan VanderMeulen [:RyanVM]]

And backed out for 110+ as well.
https://hg.mozilla.org/integration/autoland/rev/ad3d7904355589e6b14c1d0136d30bf85d646cce

Comment 41

[Henri Sivonen (:hsivonen)]

RyanVM, thank you!

Perhaps indent-only nbsp could be addressed by having a special rule saying that nbsps between the start of the line and the first character that's neither nbsp nor a regular space get replaced. This would also work for sites that have nbsps inconsistently but within indent (so far seen on w3schools). It wouldn't hurt to have the same rule also for the trailing part of the line.

Then there are sites like https://www.javatpoint.com/how-to-make-a-javascript-game that replace all spaces with nbsps. Those could be handled by replacing all nbsps with spaces if there are no spaces within some unit of inspection. Unclear what the unit of inspection should be: a line or a block element.

Considering how ad hoc w3schools is, I'm kinda worried that even after special rules like this there'd be code samples intended for copypaste where there'd be a mix of regular spaces and nbsps . Not sure how eager we should be to risk complexity and the compat risk.

Regarding complexity: How would one explain to users that the copied text depends on the selection if the check for "no spaces at all, only nbsps" operated on the intermediate serialization, which depends on the selection boundaries?

This looks a lot like we should give up and conclude that nbsp on the Web is forever damaged for plain text copy purposes.

Pierre, do you see a way forward here?

Comment 42

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/ad3d79043555

Comment 43

[Adalbert Chamisso]

(In reply to Henri Sivonen (:hsivonen) from comment #41)

This looks a lot like we should give up and conclude that nbsp on the Web is forever damaged for plain text copy purposes.

At least a single NPSP between two non-white-space characters not at the beginning of the line could be preserved to cover French punctuation, like in « Bonsior, monsieur ! ». BTW, you haven't backed out https://hg.mozilla.org/mozilla-central/rev/1fca61c97256 where NBSP are preserved in <textarea> tags. Right now, the behaviour of Firefox is inconsistent and depends where you copy from.

BTW, what was the outcome of the discussion in https://github.com/w3c/clipboard-apis/issues/173?

Comment 44

[Pierre de La Morinerie]

BTW, you haven't backed out https://hg.mozilla.org/mozilla-central/rev/1fca61c97256 where NBSP are preserved in <textarea> tags. Right now, the behaviour of Firefox is inconsistent and depends where you copy from.

The new behavior of preserving NBSP when copying from plain-text widgets was another orthogonal bug. It makes Firefox consistent with other browsers (Chrome, Safari), fixes an unwanted behavior, and wasn’t reported as an issue. I don’t think it needs to be reverted.

Comment 45

[Pierre de La Morinerie]

Apologies for the un-reactiveness – still dealing with a newborn at home.

Then there are sites like https://www.javatpoint.com/how-to-make-a-javascript-game that replace all spaces with nbsps.
(…)
This looks a lot like we should give up and conclude that nbsp on the Web is forever damaged for plain text copy purposes.

Pierre, do you see a way forward here?j

No, I don’t see how code snippets that expect the browser copy action to replace every NBSP by regular spaces could be handled. The “looking at the selection interval” seems brittle indeed, especially if Firefox is the only browser to implement this behavior.

I guess a way forward could be to make the NBSP replacement algorithm (replace NBSP adjacent to spaces and new lines) in some standard document, and then coordinate some other browsers to implement this behavior in roughly the same timeframe. That would make the issue in websites like javatpoint.com noticeable in all browsers, and likely fixed by the site authors themselves.

That’d be a lot of work for a minor issue though. Anyway at this stage it seems we can at least close the experiment, and stop trying to fiddle with NBSP in DOM content.

Comment 46

[David A. Madore]

How about offering an user-settable preference in Firefox, for all of use who want their copy-paste to not alter data and don't care about some obscure buggy broken web sites that for some reason decided to randomly change U+0020 to U+00A0 and expect the browser to somehow magically know that they should alter it back?

I'd just like a way to disable every single bit of code in Firefox that treats U+00A0 specially. I'm fine with this being a preference that I could set. Would this be so hard?

Comment 47

[Vincent Lefevre]

(In reply to Pierre de La Morinerie from comment #45)

That would make the issue in websites like javatpoint.com noticeable in all browsers, and likely fixed by the site authors themselves.

Concerning the javatpoint.com case, this is a bit strange: I don't have any NBSP issue in w3m. The HTML source doesn't seem to have NBSP characters either. So the brokenness may be unintentional. I suspect that some JS script transforms these spaces into NBSP.

(In reply to David A. Madore from comment #46)

How about offering an user-settable preference in Firefox, for all of use who want their copy-paste to not alter data and don't care about some obscure buggy broken web sites that for some reason decided to randomly change U+0020 to U+00A0 and expect the browser to somehow magically know that they should alter it back?

However, that wouldn't force authors to fix their website, and users could still be annoyed if they want a copy to behave correctly on good sites but also have to deal with NBSP issues on bad sites.

Comment 48

[Carsten Schmitz]

I am affected by this change, and it is highly annoying if you want to copy formatted code lines to bash shell and similar.
For explanation, please see https://utcc.utoronto.ca/~cks/space/blog/web/FirefoxNonbreakingSpacesCopyIssue

It would be great if there is at least a config: option to revert to the old behaviour.
I also checked using the latest Chrome version: Non-breaking spaces are not copied here when copying contents straight from a page.

Comment 49

[David A. Madore]

Alternatively to a config option, one idea would be to have two entries in the popup menu (right-click): “copy” and “copy without nbsp” (possibly with a different description) and add a help line somewhere to the effect that “copy without nbsp” is for those people who use very buggy programs like (apparently) hypermail which randomly add nbsp's to text that doesn't have them.

Of course, the really correct thing to do is fix hypermail and similar programs: adding nbsp's where there were none is simply wrong, and has always been so, especially as the space-to-nbsp transformation is a destructive operation (what if the original text already did contain nbsp's?).

Comment 50

[Vincent Lefevre]

(In reply to David A. Madore from comment #49)

Alternatively to a config option, one idea would be to have two entries in the popup menu (right-click): “copy” and “copy without nbsp” (possibly with a different description) [...]

That's not completely an alternative since a choice would have to be made for Ctrl-C.

Note also that this is not as simple because text to copy may also have NBSPs that need to be preserved (e.g. strings in French).

Comment 51

[Yuri Khan]

Many Office-like products have a function named Paste Special that activates with an alternate key shortcut such as Ctrl+Shift+V, and displays a dialog box with various transformations or options to use for pasting. Ctrl+V does the default paste.

Firefox could put the Right Thing (faithful copy) on Ctrl+C, and corrupting/corruption-fix-attempting copy on Ctrl+Shift+C, or maybe Ctrl+Alt+C if the former is occupied.

Comment 52

[Henri Sivonen (:hsivonen)]

(In reply to Carsten Schmitz from comment #48)

I am affected by this change, and it is highly annoying if you want to copy formatted code lines to bash shell and similar.

I'm sorry that I didn't get this backed out in late November.

It would be great if there is at least a config: option to revert to the old behaviour.

You can get the old behavior on Nightly today without a config option. According to the schedule on the wiki, the old behavior should come back to the release channel tomorrow (if things go according to schedule).

(In reply to Yuri Khan from comment #51)

Firefox could put the Right Thing (faithful copy) on Ctrl+C, and corrupting/corruption-fix-attempting copy on Ctrl+Shift+C, or maybe Ctrl+Alt+C if the former is occupied.

That would require other apps that consume the clipboard to have alternative behaviors available.

Comment 53

[Yuri Khan]

(In reply to Henri Sivonen (:hsivonen) from comment #52)

(In reply to Yuri Khan from comment #51)

Firefox could put the Right Thing (faithful copy) on Ctrl+C, and corrupting/corruption-fix-attempting copy on Ctrl+Shift+C, or maybe Ctrl+Alt+C if the former is occupied.

That would require other apps that consume the clipboard to have alternative behaviors available.

No it wouldn’t. User presses Ctrl+C, Firefox copies text as is. User presses Ctrl+Shift+C, Firefox copies text replacing nbsps with spaces.

I only brought up Paste Special as an example of binding non-default functionality to an alternate key shortcut.

Comment 54

[info]

This bug is affecting me big time. Stumbled across Carten Schmitz's link (https://utcc.utoronto.ca/~cks/space/blog/web/FirefoxNonbreakingSpacesCopyIssue) about this issue while troubleshooting it.

My daily work involves copy/pasting wiki instructions into a terminal, so when nbsp's are kept, creates issues with readline and some commands are not recognized anymore. The .inputrc trick does work but not convenient because you have carry the file across all systems you use.

Having as an option to globally turn on or off would be great.

Thanks guys.

Comment 55

[info]

Nevermind, just updated Firefox to 109 and bug seems gone, great stuff!

Comment 56

[Vincent Lefevre]

(In reply to info from comment #54)

My daily work involves copy/pasting wiki instructions into a terminal, so when nbsp's are kept,

I'm wondering what you mean by "wiki instructions". For instance, there are no nbsp issues on Wikipedia. There are no nbsp issues either on sites from the Stack Exchange network or GitHub/GitLab. The issue comes from the website you're using.

creates issues with readline and some commands are not recognized anymore. The .inputrc trick does work but not convenient because you have carry the file across all systems you use.

You could ask the developers of the terminal to add a "standard" feature to replace the nbsp's.

(In reply to info from comment #55)

Nevermind, just updated Firefox to 109 and bug seems gone, great stuff!

AFAIK, this is temporary, until a better solution is found.

Comment 57

[info]

(In reply to Vincent Lefevre from comment #56)

I'm wondering what you mean by "wiki instructions". For instance, there are no nbsp issues on Wikipedia. There are no nbsp issues either on sites from the Stack Exchange network or GitHub/GitLab. The issue comes from the website you're using.

There is tons of wiki platforms out there, the one I'm using is Confluence (not by choice but I have to). The issue is NOT with the site, it is with Firefox, not happening in Chrome/Chromium. Not only that, Firefox was fine before that change.

You could ask the developers of the terminal to add a "standard" feature to replace the nbsp's.

While useful perhaps, why would a terminal developer care to add extra "features" to its code base to fix issues that happen somewhere else? Again, this is a Firefox issue (not seen in other browsers) so Firefox can simply have an option to keep the nbsp's ON for the folks that really need it, instead of breaking functionality that has been around for years. It affect everyone's workflow that relies on Firefox's current behavior to do their work. This should not even be an issue, breaking existing functionality for thousands of users is not the way to fix things (unless security issues are involved). That's what options are for.

AFAIK, this is temporary, until a better solution is found.

The better solution if any is to simply make it an option that you turn on or off. Simple. Should not over think this.

Respectfully.

Comment 58

[Vincent Lefevre]

Note: your answer is badly formatted.

I don't know what Chrome/Chromium do, but here's a testcase to check that nbsp's are preserved when they need to be:

$ echo "   " | hd
00000000  c2 a0 c2 a0 c2 a0 0a                              |.......|
00000007

In Firefox 109, if I click on "Preview" (before submitting my comment) and copy the command in a shell, I get:

00000000  20 20 20 0a                                       |   .|
00000004

This is wrong! So Firefox 109 is buggy concerning nbsp preservation.

Comment 59

[Henri Sivonen (:hsivonen)]

(In reply to Vincent Lefevre from comment #58)

This is wrong! So Firefox 109 is buggy concerning nbsp preservation.

Do you have a standalone test case showing a remaining bug? The Bugzilla comment, as submitted to Bugzilla, gets copied as three regular spaces by both Firefox and Chrome.

Comment 60

[Vincent Lefevre]

The testcase seems correct: if I download this bug file with wget, I can see the 3 U+00A0 characters in the source. With w3m, if I copy the command, I get

00000000  c2 a0 c2 a0 c2 a0 0a                              |.......|
00000007

as expected. If both Firefox and Chrome give you 3 regular spaces, this is probably because you are seeing the bug.

Comment 61

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 62

[javaprogrammer]

<!-- Replace   with actual non-breaking space character on copy -->

This indicates that when copying content from the page, any instances of   (the HTML entity for a non-breaking space) should be replaced with an actual non-breaking space character so that the copied text retains the spacing. We are also providing free Java Programming tutorials that will benefit Both students and working professionals. Visit here: https://www.javatpoint.com.

Comment 63

[javaprogrammer]

(In reply to javaprogrammer from comment #62)

<!-- Replace   with actual non-breaking space character on copy -->

This indicates that when copying content from the page, any instances of   (the HTML entity for a non-breaking space) should be replaced with an actual non-breaking space character so that the copied text retains the spacing. We are also providing free Java Programming tutorials that will benefit Both students and working professionals. Visit here: https://javaprogramer.com/