902918 - Paste without formatting sometimes is greyed out

Status: RESOLVED WONTFIX

(SeaMonkey :: Composer, defect)

Description

[Rob Janssen]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 (Beta/Release)
Build ID: 20121129191119

Steps to reproduce:

Working in composer for some time pasting text from word documents.
User wants to paste plain text, not the formatting of the word document.


Actual results:

Sometimes, the "Paste without formatting" function in the right-click menu is greyed out.  Paste is still enabled, and pastes formatted data.

Comment 1

[Rob Janssen]

Does not happen all the time.  Not yet sure how to reproduce it.  Closing down
seamonkey and restarting it fixes the issue.
Using paste and then manually removing the formatting is not a good workaround
because pasting word text introduces loads of HTML garbage in the document that
cannot easily be removed from the normal view (need to go to HTML view to see
and remove it)

Comment 2

[Phoenix]

1) Is this reproducible in actual SeaMonkey version 2.20?
2) If it is, open Error Console and check if there any error when paste is not working

Comment 3

[Rob Janssen]

I am trying now, but this is on a different machine with Linux.
I installed 2.20 and opened a composer window, copied some plain text from a text
console and tried to paste: only paste is available, paste without formatting greyed out.
Closed composer window, opened a new one, copied some text from a browser window and
now I can paste in both modes (both work ok).   When I now copy plain text from a text
console I can still paste it in two ways, both the same result of course.
Error console has some remarks about CSS errors in a site that was displayed before.
Is that the correct error console?  I don't see anything related to the paste.

Comment 4

[Phoenix]

It is correct Error Console, so problem is more complicated, next two steps to test are Safe Mode (Help - Restart with Add-ons Disabled) and clean profile (http://kb.mozillazine.org/Profile_Manager)

Comment 5

[Rob Janssen]

There are no add-ons on the system where the problem was originally reported.
The profile was cleaned before and it did not make difference.
When testing with 2.20 here it is a bit erratic.
When I clear the clipboard before starting Seamonkey, both forms of paste are
disabled.  But this time when I copy something, Paste remains greyed out but
Paste without formatting becomes active.
Is there any logic in Seamonkey to determine that only one of the entries will
become available?

Comment 6

[Phoenix]

I suppose, it check if "formatting" is present and only then enables other button.
Next thing to check is current nightly build from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/seamonkey-2.23a1.en-US.win32.zip, just unpack it to separate folder and run from there. If problem will be still present, you need to do regression testing, i.e. test releases before 2.14.1 to find in which that function was broken

Comment 7

[Rob Janssen]

I was broken a couple of releases before 2.14
I don't remember exactly when.  But the user started to complain some time ago and I always
forgot to write a bug report.  At some point many composer bugs were introduced, maybe
this bug appeared in that same version.
Unfortunately because there are so many small bugs like this, I cannot afford to update
the program to a new version without rigourous overall testing before.
(it is used on a company network with IMAP mail and there have been many problems in the
latest releases which are much more critical than the paste problem)
So I can only test on my own (Linux) system which shows bugs but not completely the same
as on the Windows system.

Comment 8

[Phoenix]

As there are nobody working on Composer, the only chance to get this fixed is to find where it was broken...

Comment 9

[Rob Janssen]

I know... we already are in the process of abandoning Seamonkey because of the problems
with "nobody working on..." but still people breaking things when new versions are
released that "should be installed for security".  It is a bug pity!   But it will
take a couple of months for a migration process.
Now we are stuck to a version with bugs and cannot move forward or backward anymore.
During a few hours of testing of 2.20 I already found 2 blocking problems that are not
in 2.14.1
So I think we will have to stay at 2.14.1 until we abandon it.
Pity, it was a nice time using the program (about 12 years).

Comment 10

[Ian Neal]

(In reply to Rob Janssen from comment #9)
> I know... we already are in the process of abandoning Seamonkey because of
> the problems
> with "nobody working on..." but still people breaking things when new
> versions are
> released that "should be installed for security".  It is a bug pity!   But
> it will
> take a couple of months for a migration process.
> Now we are stuck to a version with bugs and cannot move forward or backward
> anymore.
> During a few hours of testing of 2.20 I already found 2 blocking problems
> that are not
> in 2.14.1
Do you know if these are already logged in bugzilla?

Comment 11

[Rob Janssen]

One is Bug 903451.
The other is discussed in the thread "how to control signature display"
in the newsgroup mozilla.support.seamonkey
That is not really a bug but is under the general category "developers
should not make arbitrary changes without providing mechanism to undo them".
A bug could be filed for "provide mechanism like userContent.css that works
for every user of the installation".

Comment 12

[Philip Chee]

The next thing to do is to installa windows clipboard viewer. There are several. Here
is one: http://freeclipboardviewer.com/

Then see what is actually in the windows clipboard after copying from MS Word, and before it's pasted into SeaMonkey.

Comment 13

[Rob Janssen]

I have installed this tool.  What do I need to check when the problem occurs?
I see the clipboard in several formats.  Which one is used for the option
"paste without formatting"?

Comment 14

[Philip Chee]

I'm not too familiar with the code but I think the clipboard has to containt either Text or Unicode Text

Comment 15

[Phoenix]

I wonder if this somehow related to Bug 752505...

Comment 16

[Rob Janssen]

Could be, at least the timeframe when that patch was implemented is the same as when
the problem first occurred for the user.
Hopefully I hear tomorrow about the clipboard contents when the problem occurs.

Comment 17

[Rob Janssen]

Only information until now is that the problem probably existed before Bug 752505

Comment 18

[Rob Janssen]

This bug can be closed.  We have abandoned the use of Seamonkey in the company.