Open Bug 437679 Opened 16 years ago Updated 2 years ago

copy paste add space even if not exist in selection, pasting end of line texts of format=flowed emails

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
defect

Tracking

(Not tracked)

People

(Reporter: shopik, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: platform-parity, regression, regressionwindow-wanted)

Attachments

(2 files)

example of mail
908 bytes, message/rfc822
Details
A video of the bug using the example mail
3.56 MB, application/octet-stream
Details 
1)Create an email send it to yourself, make sure its plain text.
2)Receive it, double click on any last word in line CTRL+C
3)Paste it somewhere and see additional space even there no space in selection and not even in original mail
I've attached message for example just in case.

version 3.0a2pre (2008060603)
Attached file example of mail — 

    
    

    
  
Doesn't seem to a problem on linux. The application you paste into isn't adding the space?

    
    

    
  
I'm paste into notepad or any dialog box like start->run. So I'm sure it isn't problem of third party program I'm pasting.

    
    

    
  
I do see this problem on linux (Ubuntu) too.
version 3.0a2pre (2008060703)

    
    

    
  
WFM in version 3.0a2pre (2008060803) WinXP

my config settings
layout.word_select.eat_space_to_next_word = true
mailnews.display.disable_format_flowed_support = false

also check Bug 99922 and Bug 215068 whether that has some thing to do with this

    
    

    
  
I don't have any additional spaces. If I open message source and copy past from there no problem at all. And as example your bugmail comment I copy and paste just fine last words.

    
    

    
  
using actual message, not source:
yes, vista version 2.0.0.12 (20080213)
no XP version 3.0a2pre (2008061103)

    
    

    
  
quite fantastic, I never seen this in 2.0.0.x tree, but start seen this only on trunk.

    
    

    
  
FWIW ,vista
I see it in both 2.0.0.14 and 3.0a1 ID:2008050715
(will try 3.0a2 when get it ..)

+ if the paste is in TB compose seams "it further plays with it's own weirdness": 
tb2 (one fw msg added ** 2 lines after last word
-select only the [word], no dbclick
-the cursor position looks ok, [word|] c end of word..
-on second paste, the space shows like: ![word word|] cursor end of word.. so on for n pastes till wraps (on the next line ok, no spaces)
-del all and seams that wrap solved it ..
-if you paste first and type, no problem ..
(while notepad paste [word ] like you say )
*this cannot reproduce but for one of the msg I tested, a fw where word is not really last word ..

tb3 -not quite dramatic, shows as described, BUT initially backspace dels the space And the last char in one step. Like: [example ] 1backsp=> [exampl]. Ha

    
    

    
  
shoot me for not following instructions.
I see this in version 3.0a2pre (2008061103)

look for a dupe

    
    

    
  
(what i say in comment 9 on tb3 compose issue seams bug 354778)
related? Bug 332511 Bug 332510 Bug 290565
maybe related bug 342637 (old)

    
    

    
  
I believe this is depends on encoding or something else in headers. Wayne you could check any emails comes from Przemek for example - these mails don't have such problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
same as Bug 432415?  which is an artifact of bug 406062 - which blows my mind because I didn't realize there had been a deliberate change to trunk.

    
    

    
  
Bug 432415 kinda reverse version of this bug in this bug we are copy FROM TB to external app and bug 432415 describe coping TO FF. And this only apply so far only windows platform Linux for example not affected

    
    

    
  
WFM
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081210 Shredder/3.0b2pre
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090105 Shredder/3.0b2pre 
Appears again, it converts CR/LF to additional space I think
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b5pre) Gecko/20090512 Shredder/3.0b3pre

still on
1. sent mail with normal ending word, no space [word]
2. recieve, open to see, select last word with dbclick
3. paste

result: [word] copy/paste -> [word ] 
+ in tb composer cursor is at the end [word |] 
but backspace erases both space and last letter to a [wor|]

    
    

    
  
I can confirm this bug with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0.

It is especially annoying when copying from mail containing passwords!!!
Keywords: pp
Summary: copy paste add space even if not exist in selection → [win only] copy paste add space even if not exist in selection

    
    

    
  
This is still true, I've got new OS installed and easily confirm with attached "example of mail" by coping "example" word.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100224 Lanikai/3.1b1pre

    
    

    
  
This is not windows specific.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All

    
  
Status: REOPENED → NEW
Summary: [win only] copy paste add space even if not exist in selection → copy paste add space even if not exist in selection

    
    

    
  
In 2.0.0.24 it show space in selection even so there no space in source, if I set layout.word_select.eat_space_to_next_word to false it stop selecting extra space and copy normaly but in Lanikai/3.1.4pre this not helps anymore.

    
    

    
  
Here is bonsai link latest 2006-04-20 build(win32) show space in selection 2006-04-21 build(win32) doesn't show space in selection.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-04-20+00%3A00%3A00&maxdate=2006-04-21+23%3A59%3A00&cvsroot=%2Fcvsroot
probably Bug 235223 cause regression.
TB still copy extra space even there no such in original but this is probably another bug.
Blocks: 235223

    
    

    
  
As mentioned in comment 18 and nicely explained in duplicate bug 612856, this makes copy/paste of passwords from e-mail fail.

I have encountered this on Linux: Thunderbird 14.0 on Fedora Core 16.

    
    

    
  
This bug is still present in thunderbird 17.0.3 on F18. I have several colleagues also very annoyed with this problem, so hope someone can soon fix it.

    
    

    
  


  
This is on Fedora 18 (64bit), Fresh install of thunderbird 17.0.4 from repository with no extra plugins.

    
    

    
  
I just made some tests and it seems to be related to the content type of the E-mail.
On my system this bug only occurs on mails which have the "format=flowed" in the content-type.

Therefore for example all mails with 

Content-Type: text/plain; charset=ISO-8859-15; format=flowed

were affected of this bug.

Tested with Thunderbird 17.0.4 on Win7-64

    
    

    
  
Ok, is see that now on trunk.
Summary: copy paste add space even if not exist in selection → copy paste add space even if not exist in selection, pasting end of line texts of format=flowed emails

    
    

    
  
See it in Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 SeaMonkey/2.17.

Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 8bit

    
    

    
  
I suspect Bug 622103 is a duplicate of this one.

    
    

    
  
I just found that by going to config editor and setting:
mailnews.display.disable_format_flowed_support = true
the copy paste problem does not happen anymore. So that can maybe be a workaround until flowed format is fixed

    
    

    
  
Maybe this (mailnews.display.disable_format_flowed_support = true) should be default in new versions? I have no idea if/when it gt's fixed. It's open for 5 years...

    
    

    
  
I can confirm that the described workaround works. Seems not to have any visible drawback.

    
    

    
  
Some cases of this issue will be fixed by the patch for bug 1043118.
Depends on: 1043118

    
    

    
  
On linux, TB 31.5.0 mailnews.display.disable_format_flowed_support = true doesn't work.

    
    

    
  
(In reply to tony den haan from comment #40)
> On linux, TB 31.5.0 mailnews.display.disable_format_flowed_support = true
> doesn't work.

sorry, it worked after a while :)

    
    

    
  
it's working for me without this fix now, on ubuntu 15.10/kde5/TB 38.8.0

    
  
Severity: minor → S4

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: