User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124) Gecko/20091221 Firefox/3.5.7 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:126.96.36.199) Gecko/20091204 Thunderbird/3.0 If you double click to select a word in an email and it is the last word on the line then copy the selection the clipboard ends up with an extra 'space' on the end of the text. Reproducible: Always Steps to Reproduce: 1. View any email 2. Double click on the last word on a line of text in order to select it 3. Select copy from the edit menu (or use command-c) 4. Compose a new email 5. Paste the clipboard into that message Actual Results: The copied word plus an extra space is inserted into the destination. This is very awkward when you have copied a password and pasted it into an external application or login box. You cannot see the 'space' and the login fails. Expected Results: Only the highlighted word should be copied. I suspect that the issue lies within what is highlighted by the double click. I'm suspecting that the end of line character is actually being selected and copied rather than a space. Double clicking on a word in the middle of a line does not show this issue.
Laurent is this a manifestation of bug 524975 ?
@ludovic : no. bug 524975 is related to a regression appeared in 1.9.2, and this issue seems to be related to the 1.9.1 branch. We should verify if this bug still exists in the current trunk and/or 1.9.2 branch.
(In reply to comment #2) > We should verify if this bug still exists in the current trunk and/or 1.9.2 > branch. I don't see that on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2pre) Gecko/20100118 Lanikai/3.1a1pre
I do see this in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2pre) Gecko/20100118 Lanikai/3.1a1pre. You have to be at the end of a line and not have any punctuation there. Simply double clicking on the word and pasting it into a new email causes an extra space to be pasted.
(In reply to comment #4) > I do see this in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; > rv:1.9.2pre) Gecko/20100118 Lanikai/3.1a1pre. You have to be at the end of a > line and not have any punctuation there. Simply double clicking on the word and Thanks for the more details. Still doesn't do it for me. Can you launch Thunderbird in -safe-mode (http://kb.mozillazine.org/Safe_mode) and see if it's still there ?
Yes, it does. However, I've just noticed that it doesn't do it for every line in an email. It seems to be related to ones where there's a true end of line present, as opposed to the line being word wrapped. So, for example: This is some text<return> This is some more text and more and more and more and more and more and more and more and more and more and more and more and more and more and more and more and more and more and more<return> Which results in an email that looks like this: This is some text<return> This is some more text and more and more and more and more and more and more and more and more and more and more and more and more and more and more and more and more and more and that<return> Then only the word 'text' on the first line and the 'that' would cause the issue. The 'more' on lines 2 and 4 and the 'and' at the end of line 3 would not.
Joe does this rings a bell ?
The issue here is different for html vs. plaintext. For html, double-click the last word in a line copies just that word to the clipboard. In plaintext, a space is added to the clipboard. You can check that by copying into notepad or some other text editor. I'm sure this was done intentionally in the plaintext editor, since most of the time you would want the space there to start the next word. Never the less, the behaviors are different, and confusing, since the highlighted area copies different data to the clipboard, html vs. plaintext. A simple workaround is to left mouse and drag over the the text to select, rather than double-click.
Yes, I'm using plain text. If this space was added deliberately it's a truly appalling idea. It's the kinda of nonsense you get from M$. It assumes you, as the programmer, know better than the users what they intend to do. For example the reason I found this is because I double clicked a password sent to me. I then switched application and pasted it into a password dialog. In the password dialog you cannot see that there's an extra space in the string. Sure you could count the *s but who wants to do that. The upshot of this 'helpful' behaviour is that the password is incorrect. Double click on text on a mac or windows selects a word, copy should copy the selection, paste should paste the contents of the clipboard. Nothing else is acceptable.
Just another thought, I don't believe this is the case. If I double click on a word in the body of text and do the same copy/paste operation I do not get the extra space.
(In reply to comment #9) > Double click on text on a mac or windows selects a word, copy should copy the > selection, paste should paste the contents of the clipboard. Nothing else is > acceptable. I'm not being contentious here, just trying to understand the use case. Double-clicking for me in XP selects the word+ the space following the word. This might be different in other than XP. I assume that the case where the space gets added for the last word in a line was intended to mimic that. At any rate WYSIWYG should prevail. So confirming as new.
I'm on a Mac and I specifically said that the word was at the end of a line. There is no space following the word so the highlight cannot possibly be coping it. If I double click in the body it does not highlight the space and it does not copy the space.
Ian, Try this: Go into ConfigEditor and filter on "layout" no quotes. Look for layout.word_select.eat_space_to_next_word and set it to false. Does this help with your problem. For me in XP double click now selects only the word, and the last word in a line seems to copy OK
Nomis101, Would you mind testing the effect of the pref change I suggested in comment 13 on a Mac.
It's false to begin with, which in my opinion is how it should be. This is especially true given the hidden nature and dire warnings you have to go through to get to it. As I've said before this is not that it is highlighting a space in the middle of a line and copying it correctly, that does not happen. It is copying an extra space when you are at the end of a line and there is no space there to copy. It works correctly when there is a space there and not when there isn't. I strongly suspect that it is copying some sort of 'end of line' character and that is turning into a 'space' on pasting.
(In reply to comment #14) > Nomis101, > Would you mind testing the effect of the pref change I suggested in comment 13 > on a Mac. I'm not sure, because I'm not able to reproduce it. I don't see this in my 3.2a1pre build. Therefore I've downloaded TB 3.0.1 to test this. But I also can't reproduce this with 3.0.1. I looked into my ConfigEditor for layout.word_select.eat_space_to_next_word and it was allready set to false. So I set it to true and tested again. But I was still not able to reproduce. If I select the last word from a text and paste© it into a new mail only the selected word is copied, in all my testcases (also in safe-mode). I've also tested html/plaintext, nope. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:188.8.131.52) Gecko/20100111 Thunderbird/3.0.1
Have you read comment 6. It's important to making it work (or not in this case). When making your email type one line and press return. Repeat a few times. It's the last word on the line that seems to show the issue. I've just tried this again as follows (without 'Compose messages in HTML format' turned on): - Compose a new message. - Type 'One' and press return (without the 's). - Type 'Two' and press return. - Type 'Three' and press return. - Send the message. - Read the new message and double click on the 'One'. - Compose a new message. - Click in the body of the message. - Select paste. I get 'One ' in my message.
To Summarize: 1. Not sure why the default setting of layout.word_select.eat_space_to_next_word seems to be different in Win Vs. Mac 2. There seems to be 2 different behaviors for double-click on Win Vs. Mac Ian, there is obviously something different in your local setup contributing here. Until we figure out exactly what that is, and establish steps to reproduce, this bug won't get much traction. Can you think of any specific optional settings in TB, or in your O/S defaults that might make for more reliable "steps to reproduce" In the meantime, I'll leave this as "new" simply on the basis of the difference in behavior of double-click between Mac and Win (Win includes space after word in body)
There's no mystery about the Win vs. Mac eat_space difference: Windows and OS/2 set it to true because it's platform-native behavior, Mac and Linux set it to false because it's not.
(In reply to comment #17) > I've just tried this again as follows (without 'Compose messages in HTML > format' turned on): > > - Compose a new message. > - Type 'One' and press return (without the 's). > - Type 'Two' and press return. > - Type 'Three' and press return. > - Send the message. > - Read the new message and double click on the 'One'. > - Compose a new message. > - Click in the body of the message. > - Select paste. > > I get 'One ' in my message. I get 'One'. And I followed your steps (but after double clicking the 'One' I copied it into my clipboard). There must be something different in our prefs I suppose...
Ian, Since your symptoms don't seem to be reproducible, and since the "eat space" pref is working "as designed" I'm marking this incomplete. If you can refine the "steps" or otherwise elaborate, we can revisit this bug. Thanks for filing.
Just for clarity this is the true set of steps. I can see that it is not always reproducible with any old message. But it always happens when I get messages from sent from Thunderbird as the mail client. It only seems to happen on plain text messages ie those that are sent with 'Compose message in HTML format' turned off in account settings. The steps, this time including the copy and describing the fact that this was done using command key shortcuts in case that matters: - Compose a new message. - Type 'One' and press return (without the 's). - Type 'Two' and press return. - Type 'Three' and press return. - Send the message. - Read the new message and double click on the 'One'. - Copy using Command-c. - Compose a new message. - Click in the body of the message. - Select Command-v. It is also important to not put any punctuation on the end of the items as this make a difference. It has to be 'One' and not 'One.' or 'One,' for example. Can any one suggest other settings that I can check. Would you like me to post my settings file? This is a real pain for me and it doesn't happen if I go back to Thunderbird 2.x
ps. I don't think resolved fixed is the correct status for this. WORKSFORME would better represent the situation. Just to be clear about the above the message should end up looking like this: One Two Three ie the ' should not appear in the message.
Ah, I can now see there's a bug in Bugzilla. I see that I do not have a status of 'Incomplete' in my list. Because of that when I added the comment it was changed to the first item in the list which was FIXED. Questions, should I be able to see Incomplete? If not how can I as reporter ever comment on the message? Should I file this as a bug against Bugzilla?
Not sure how that happened Ian. I'm resetting to Incomplete, based on the fact that you don't see the problem when using TB2 Worksforme would dispatch your report as a non-bug and I think it is real, but lacks the exact conditions to be reproducible. I don't have access to a Mac, so I asked Nomis101 to help out, but there is always a chance that someone else will see the same problem and clarify the "steps"
I do. I don't have incomplete in my list of options so each time I post a message it's getting set to 'fixed' as it's the first item in the list. I've found a bug report about removing the 'incomplete' from the menu for certain people and have pointed out the problem there. Sorry you are going to have to re-mark this as incomplete if required. I've now had three other people here reproduce it using my exact steps. In each case the eatspace option is set to off as default.