Closed Bug 902918 Opened 12 years ago Closed 11 years ago

Paste without formatting sometimes is greyed out

Categories

(SeaMonkey :: Composer, defect)

SeaMonkey 2.14 Branch
x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bugzilla, Unassigned)

Details

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.
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)
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
Flags: needinfo?(pe1chl)
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.
Flags: needinfo?(pe1chl)
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)
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?
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
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.
As there are nobody working on Composer, the only chance to get this fixed is to find where it was broken...
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).
(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?
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".
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.
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"?
I'm not too familiar with the code but I think the clipboard has to containt either Text or Unicode Text
I wonder if this somehow related to Bug 752505...
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.
Only information until now is that the problem probably existed before Bug 752505
This bug can be closed. We have abandoned the use of Seamonkey in the company.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.