Open Bug 303597 Opened 19 years ago Updated 1 year ago

copy to clipboard adds a leading/trailing space unexpectedly

Categories

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

Product:
Core
Component:
DOM: Selection
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: tony-mozilla1, Unassigned)

References

(
URL
)

Details

(Whiteboard: tpi:+) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

1) If you have a markup tag, followed by some whitespace (not including
newlines), followed by some text, ie:

<td> testing1</td>
<td>
  testing2
</td>

then copying text beginning with the first word to the clipboard may produce
unexpected results, as follows:

If you select the first word by dragging the mouse over it, then a subsequent
copy-to-clipboard operation will add a leading space to the clipboard.

2) If you have some text, followed by some whitespace (including newlines!),
followed by a markup tag, ie:

<td>testing3 </td>
<td>testing4
</td>

then, if you load the page in firefox and select the last word on that line by
double-clicking on it, then a subsequent copy-to-clipboard operation will add a
trailing space.

This seems to happen only if there is any whitespace (including newlines)
between the leading or trailing markup tag and the text.

If there is markup on the same line with no leading/trailing whitespace, ie:
    <td>testing1 testing2</td>
    <p>testing3 testing4</p>
then everything works as expected.

Reproducible: Always

Steps to Reproduce:
1.  Create a test.html file with the following content, ensuring to preserve the
whitespace before the word "testing1":

<html><table><tr>
<td> testing1</td>
<td>
  testing2
</td>
<td>testing3 </td>
<td>testing4
</td>
</tr></table></html>

2.  Open the page in firefox, and select the word "testing1" by dragging your
mouse pointer over the word with the left mouse button pressed.  It should be
highlighted now.  Assert that there is no extra whitespace visibly highlighted
before or after the word. Press CTRL-C to copy to clipboard.  

3.  Paste the clipboard somewhere (ie: in the firebox address bar), and observe
that the pasted word (excluding quotes) is actually " testing1" with a leading
space.  This is counter-intuitive, as the leading space was not highlighted.

4.  Now select the word "testing2", this time by dragging your mouse pointer
over the word with the left mouse button pressed. It should be highlighted now.
 Assert that there is no extra whitespace visibly highlighted before or after
the word. Press CTRL-C to copy to clipboard. 

5.  Paste the clipboard somewhere (ie: in the firebox address bar), and observe
that the pasted word (excluding quotes) is actually "testing2 " with a trailing
space.  This is counter-intuitive, as the trailing space was not highlighted.


Actual Results:  
see above steps

Expected Results:  
In both cases, I would expect that only the word "testing" is pasted, since that
is what was highlighted.
*** Bug 303582 has been marked as a duplicate of this bug. ***
> Expected Results:  
> In both cases, I would expect that only the word "testing" is pasted, since that
> is what was highlighted.

oops... I meant "testing1" or "testing2" should be pasted.  Only the selected
word, with no surrounding whitespace, should be copied to the clipboard and
later pasted. 
Reproducible with Mozilla 1.8b1, but I only get extra leading spaces ("
testing1" and " testing2"). WFM with Deer Park a2 and SeaMonkey/20050727
("testing1" and "testing2"). Related to Core bug 157379?
Reproducible with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
This bug plagues me to death. I have noticed though when I paste the contents into a ms-dos command prompt it shows " testing1 .gtk-bookmarks testing2 .gtk-bookmarks". If I paste it into any windows application it just posts a leading space or tab.
do you see this problem also in version 3.5 or newer?
Component: General → Widget
Product: Firefox → Core
Whiteboard: [closeme 2010-02-10]
QA Contact: general → general
Works for me using - Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
and
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100116 Firefox/3.6

Using
data:text/html,<html><table><tr><td> testing1</td><td>  testing2</td><td>testing3 </td><td>testing4</td></tr></table></html>
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
I still have this issue with Firefox Nightly on Windows 7 64 bits (27.0a1 (2013-10-07)).

The HTML is :

    <p>
      <b>clé:</b>
      82484950
    </p>

When I double click on "82484950" the selection looks good, then I CTRL+C to copy it but when I CTRL+V to paste the text in a windows app, there is an unexpected space at the beginning.
Just noting that wlach, myself, and Treeherder sheriffs observe this behavior in https://treeherder.mozilla.org in our Log viewer. To reproduce:

o open https://treeherder.mozilla.org
o select any completed 'Job' (eg. 'B', 'Cpp', etc) in the right hand job table
o click on the 'Log' icon in the bottom left navbar
o follow steps per https://bugzilla.mozilla.org/show_bug.cgi?id=1144728#c0.
Let's reopen this.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
Whiteboard: [closeme 2010-02-10]
The testcase from the dupe reproduces this for me on Windows 8.
URL: data:text/html,word1%20%20word2
OS: Windows 2000 → All
Hardware: x86 → All
Component: Widget → Widget: Win32
Priority: -- → P2
Whiteboard: tpi:+
I should note: I don't think this is Windows/Win32-only. My duplicate
bug 1270919 happens on Linux, for example. I wouldn't be surprised if
it also duplicates on Mac OS X Firefox as well (and it's easy to test
if someone wants to find out; see bug 1270919 for an extremely minimal
test case).
(In reply to Chris Siebenmann from comment #13)
> I should note: I don't think this is Windows/Win32-only. My duplicate
> bug 1270919 happens on Linux, for example. I wouldn't be surprised if
> it also duplicates on Mac OS X Firefox as well (and it's easy to test
> if someone wants to find out; see bug 1270919 for an extremely minimal
> test case).

I concur, opening the URL: data:text/html,word1%20%20word2

and double-clicking 'word2' and pasting on OS X reproduces the issue.

Jim, maybe this needs to live in Core::Selection if we don't think it's widget code that's doing this? Or serialization from HTML selection to plaintext? Not sure.
Component: Widget: Win32 → Widget
Flags: needinfo?(jmathies)
Lets start by investigating the cause. I'll bump the priority up as well.
Flags: needinfo?(jmathies)
Priority: P2 → P1
See Also: → 1298706
Moving to p3 because no activity for at least 24 weeks.
Priority: P1 → P3
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:spohl, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(spohl.mozilla.bugs)

I'm no longer able to reproduce this. Tentatively closing.

Status: REOPENED → RESOLVED
Closed: 14 years ago → 1 year ago
Resolution: --- → WORKSFORME

The reproduction for me is now:

<html>
<div> <span> Testing 1 »
Testing2</span></div>
</html>

If I double-click select 'Testing2' and paste it, I get a leading space. This happens for me in 106.0.1 (official Mozilla build, just installed). It's possible that the leading space in the HTML in front of 'Testing2' is important.

I'm going to assign this to a (hopefully) better component.

Status: RESOLVED → REOPENED
Component: Widget → DOM: Selection
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.