271010 - caret positioned randomly after paste of styled text to compose window

Status: RESOLVED INCOMPLETE

(Core :: DOM: Editor, defect)

Description

[Alexander Sack]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)

If you compose a message and select some text out of openoffice and then copy it
to the compose window, the caret is place at the top of the compose window.
Don't know if this is true for mailnews too.

For me it does *not* look like https://bugzilla.mozilla.org/show_bug.cgi?id=161309.

THe bug was worse in 0.8. Now in 0.9. pasting plain text out of emacs works. For
details see the debian bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279656.




 

Reproducible: Always
Steps to Reproduce:
Copied from the bug report mentioned above:

> The bug is still present, and trivially reproduceable:
> 
> 1. Compose an email in thunderbird.  Write some lines.
> 2. Open or create some document in OpenOffice. 
> 3. Mark a few lines in the openoffice document
> 4. Paste these lines into the bottom of the thunderbird
>     email message by pressing the third mouse button.
> 5. Notice how stuff gets pasted just fine, but the cursor
>     also jumps up to the beginning of the first line.  This
>     behaviour is particularly aggravating when the message
>     is several pages long so I have to scroll down again and
>     again. 
Actual Results:  
basd caret position

Comment 1

[Mike Cowperthwaite]

Possibly a dupe of bug 131854?

Comment 2

[Alexander Sack]

don't think so. At least the pasting works in this comments box (so other
text-editors then the mozilla compose editor are not affected), so it is not
something generally wrong. Appears to be referrable to some specific clipboard
data flavours.
For example pasting content from abiword, openoffice, etc. always produces this
error, but pasting something styled from html works. plain text works as
expected too.

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Alexander Sack]

easily reproducible ... don't see how to provide more info.

Comment 5

[Wayne Mery (:wsmwk)]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279656 was marked fixed. 
But no response here from Alexander, so closing incomplete.