If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Extra newline added to selection when double clicking

NEW
Unassigned

Status

()

Core
Selection
--
major
10 years ago
9 years ago

People

(Reporter: Ali Ebrahim, Unassigned)

Tracking

unspecified
x86
Windows XP
Points:
---
Bug Flags:
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Read comment 6 for better summary)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
Created attachment 322471 [details]
Demo of bug behaviour

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.
Flags: blocking-firefox3?
(Reporter)

Comment 1

10 years ago
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
(Reporter)

Comment 2

10 years ago
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
(Reporter)

Updated

10 years ago
Component: General → DOM to Text Conversion
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → dom-to-text
(Reporter)

Comment 3

10 years ago
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?
Component: DOM to Text Conversion → General
Product: Core → Firefox
QA Contact: dom-to-text → general
(Reporter)

Updated

10 years ago
Flags: blocking-firefox3?
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?
(Reporter)

Updated

10 years ago
Blocks: 406062
(Reporter)

Comment 5

10 years ago
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?
(Reporter)

Comment 6

10 years ago
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)
No longer blocks: 406062
Component: General → Selection
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → selection
Summary: Extra character (possibly newline) gets copied into input box → Extra newline added to selection when double clicking
Whiteboard: Read comment 6 for better summary

Updated

10 years ago
Blocks: 344417
(Reporter)

Updated

10 years ago
Flags: wanted1.9.0.x?
Not wanted for 1.9.0.x.
Flags: wanted1.9.0.x? → wanted1.9.0.x-

Comment 8

9 years ago
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)

Comment 9

9 years ago
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".
You need to log in before you can comment on or make changes to this bug.