Open Bug 303597 Opened 20 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:+,domcore-bugbash-triaged)

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: 16 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: 16 years ago → 3 years 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 → ---

Using Nightly Fx 133 on Win11, I can reproduce this using the STRs in comment 14. I have no leading space when reproducing comment 20.

Whiteboard: tpi:+ → tpi:+,domcore-bugbash-triaged
You need to log in before you can comment on or make changes to this bug.