In the attached HTML demo file, there are two versions of the same "password", a1b2c3d4. There is also a input box. When you double click to select the first occurrence of a1b2c3d4 and copy, and then paste it into the input box, you get the following input: "a1b2c3d4 " (note the extra space on the end) When you double click to select the second occurrence of a1b2c3d4 and copy, and then paste it into the input box, you get the following input: "a1b2c3d4" The behaviour in the first case did not happen in FF 2.0.x nor does it happen on any other browsers (IE, Safari, etc). It basically breaks copying and pasting passwords from emails. That's why I'm also nominating for blocking-firefox3. More oddities: When I copy case 1 from IE7 and paste into FF 3.0 RC1 input box, it works (no trailing space). When I copy case 1 from FF 3.0 RC1 to IE7, it works (no trailing space). Within IE7 it works. Only within FF 3.0 RC1 it doesn't work. I don't know how to reduce this any further and couldn't find an open bug, so here's hoping someone else can.

For some reason I thought Bugzilla would mark down the reporting UA somewhere in the bug. Since it didn't, here's what I'm testing on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008051206 Firefox/3.0

In the following build the incorrect behaviour in case 1 does NOT happen (NO trailing space after the pasted text): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091504 Minefield/3.0a8pre In the following build the incorrect behaviour in case 1 DOES happen (there IS a trailing space after the pasted text): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008052503 Minefield/3.1a1pre

Following build works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121705 Minefield/3.0b3pre This one doesn't: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121805 Minefield/3.0b3pre The bug is caused by the checkin from bug 406062. Changing editor.singleLine.pasteNewlines to 2 is what caused this problem. Can we consider to revert that change back again?

Works for me on Mac: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008052604 Minefield/3.0pre I imagine that when you double-click select on Windows, we're also selecting the newline, so you get the space when pasting?

Yes, on Windows it selects the newline (but seems maybe only in Gecko based products). When you paste it into Notepad it pastes a1b2c3d4 followed by a newline (no space). In FF, with editor.singleLine.pasteNewlines set to 2, it converts the newline to a space. What's also interesting is that when you copy the case 1 text from IE7 it *doesn't* pick up a newline, which is why the paste from IE7 into FF worked. The behaviour of copying a newline for this hasn't changed for a long time. I noticed this originally while copying from Thunderbird 2.0.0.14 to Firefox 3.0 RC1 so the copy behaviour has been the same for a long time, only the paste behaviour has changed. But why is Mozilla's copy behaviour different from other software such as IE7 and Notepad? Another bug?

I discussed this with a few people on IRC, and the real bug seems to be that in case 1, a newline is getting copied. In other Windows apps (like IE7 and Notepad), this does not happen. Therefore the checkin from bug 406062 did not cause a bug, it just exposed another bug, because it converted the extraneous newline into a space, which previously just got discarded. Double clicking text in case 1 and then doing a javascript:selObj = window.getSelection();window.alert(selObj); gives the following result: "a1b2c3d4 " Which suggests that it may be a selection bug. Not sure if this is a dupe or not. (Sorry for so much bugmail)

Not wanted for 1.9.0.x.

Cannot reproduce this in latest nightly (3.2a1; Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090121 Minefield/3.2a1pre)

The previous information applies to the testcase sent in by the reporter ONLY. However, the bug is there if you try to double-click an article number on ebay.com and try to paste it using CTRL-C to another location. I can confirm that this will insert an additional space at the beginning. So "123456789" would become " 123456789".