Chris's Wiki :: blog/web/FirefoxCutAndPasteBug

A weird little Firefox glitch with cut and paste

May 6, 2016

Yesterday I wrote about Chrome's cut and paste, so to be fair today is about my long standing little irritation with Firefox's cut and paste. Firefox doesn't have Chrome's problem; I can cut and paste from xterm to it without issues. It's going the other way that there's a little issue under what I've now determined are some odd and very limited circumstances.

The simplest way to discuss this is to show you the minimal HTML to reproduce this issue. Here it is:

<html> <body>
<div>word1
  word2</div>
</body> </html>

If you put this in a .html file, point Firefox at the file, double click on 'word2', and try to paste it somewhere, you will discover that Firefox has put a space in front of it (at least on X). If you take out the whitespace before 'word2' in the HTML source, the space in the paste goes away. No matter how many spaces are before 'word2', you only get one in the pasted version; however, if you put a real hard tab before word2, you get a tab instead of a space.

(You can add additional ' wordN' lines, and they'll get spaces before the wordN when pasted. Having only word2 is just the minimal version.)

You might wonder how I noticed such a weird thing. The answer is that this structure is present on Wandering Thoughts entry pages, such as the one for this entry. If you look up at the breadcrumbs at the top (and at the HTML source), the name of the page is structured like this. As it happens, I do a lot of selecting the filenames of existing entries when I'm writing new entries (many of my entries refer back to other entries), so I hit this all the time.

(Ironically I would not have hit this issue if I didn't care about making the HTML generated by DWiki look neat. The breadcrumbs are autogenerated, so there's no particular reason to indent them in the HTML; it just makes the HTML look better.)

This entry is also an illustration of the use of writing entries at all. Firefox has been doing this for years and years, and for those years and years I just assumed it was something known because I never bothered to narrow down exactly when it happened. Writing this entry made me systematically investigate the issue and even narrow down a minimal reproduction so I can file a Firefox bug report. I might even get a fixed version someday.

PS: If you use Firefox on Windows or Mac, I'd be interested to know if this cut and paste issue happens on them or if it's X-specific.

Comments on this page:

By Aristotle Pagaltzis at 2016-05-06 03:38:27:

I get the same thing on OS X.

By lvps1000vm at 2016-05-06 06:29:35:

Firefox 46 on Windows. It also happens.

By Evaryont at 2016-05-06 06:50:09:

I wanted to say this could have been fixed by setting layout.word_select.eat_space_to_next_word, which fixes my annoyance with Firefox: it will select a space before/after a word when you double click it. Setting it to false will stop this behavior, double clicking on a word will only select it and nothing else.

No effect on the bug though. You still get an extra leading space. (Windows, Firefox 45.0.2 64-bit)

By Brendan Long at 2016-05-06 09:10:02:

Isn't this the correct thing for the browser to do, since any amount of whitespace is converted to a single space, not removed?

By Brendan Long at 2016-05-06 09:16:57:

I posted too soon, here's the relevant part of the CSS spec:

https://www.w3.org/TR/CSS2/text.html#white-space-model

Whether or not the line break should be removed is left ambiguous, but spaces and tabs surrounding it should definitely be removed:

Each tab (U+0009), carriage return (U+000D), or space (U+0020) character surrounding a linefeed (U+000A) character is removed if 'white-space' is set to 'normal', 'nowrap', or 'pre-line'.

By cks at 2016-05-06 13:52:52:

If you explicitly selected whitespace, removing it would clearly be the wrong thing to do during a cut and paste. However, you don't in this case; you select just text (that's a single word), with no whitespace.

(Also, I don't think CSS necessarily dictates how a browser handles mouse-based cut and paste selections.)

By cks at 2016-05-06 14:15:26:

I've now filed this bug as #1270919, so we'll see if anything happens here. It may be related to a long-standing Firefox bug, #303597, but that one's so old I think it predates when I started seeing this Firefox behavior.

By Dan Astoorian (Dan.Astoorian) at 2016-05-06 14:28:16:

It gets even more fun than that. Try this:
   <html> <body>
   <div>word1
   ^Iword2</div>
   <div>word3^I
   ^Iword4</div>
   </body> </html>
where ^I represents a hard tab.

Select and paste word2, and you'll get a hard tab. Select and paste word4, and you'll get a space.

--Dan

By db48x at 2016-05-08 16:55:08:

You remind me that I need to investigate the bug that causes multiple spaces to show up in the middle of a selection; I can't reproduce it with your testcase, so it must be a different edge case somehow.

By Grant at 2016-05-11 22:37:50:

I wonder if this has anything to do with CDATA in the DOM in front of the word that you want to copy.

Written on 06 May 2016.

«	My annoyance with Chrome's cut and paste support under X

'Fair share' scheduling pretty much requires a dynamic situation