525601 - widget is not always able to initialise OLE (somehow triggered by various third party software e.g. McAfee Site Advisor, TortoiseHg)

Status: VERIFIED FIXED

(MailNews Core :: Simple MAPI, defect)

Description

[fwilsey]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0

Cutting or copying text, links, whatever from anywhere in SM 2.0 does not appear to place the cut or copied text in the Clipboard. When I try to paste what I cut or copied, the Paste options are grayed out. 

The Paste function DOES work, since I can cut/copy from another app and paste it into SM 2.0.

Reproducible: Always

Steps to Reproduce:
1. Cut or copy something from within SM 2.0. For example, some text from the www.seamonkey-project.org page. 
2. Attempt to paste the aforementioned text into something else, for example a new Composer page.
3.
Actual Results:  
If there is nothing in the Clipboard, the Paste options are grayed out. If you cut/copied something to the Clipboard previously, that info will be pasted. 

Expected Results:  
Ability to paste whatever I cut/copied from within SM 2.0

Other than this I like the new version! I did check to see if someone else had submitted this, but could not find where anyone had. 

Also tried completely re-installing SM 2.0, problem is still there. 

Thanks in advance!

Comment 2

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0] (release) (W2Ksp4)

WorkForMe...

Comment 3

[Lionel Raymond]

I have the same issue. Using Windows 2000 Pro sp4.
Uninstalled previous SeaMonkey version (except profile) before installing version 2.0.
Only add-on installed is AdBlock-plus.
Previous version had ietab, AdBlock-plus, Forecastfox and Multizilla installed.

Tried creating a new profile, issue persists.

Comment 4

[Jens Hatlak (:InvisibleSmiley)]

Please
1. check whether bug 334500 comment 26 applies to you
2. check whether the problem also appears with Firefox 3.5
3. check whether other applications running in the background interfere

Comment 5

[NoOp]

I am unable to reproduce in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091007 SeaMonkey/2.0
- WinXP Professional SP3
- Win2KPro SP4
Copy & pasted into Wordpad & SeaMonkey 2.0 Composer

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091017 Lightning/1.0pre SeaMonkey/2.0
- Ubuntu (linux) 9.04 & 9.10
Copy & pasted in to Composer, and aross a VNC connection from WinXP to this bug report: 
The SeaMonkey® Project

Comment 6

[sereenie]

I’m having the same problem and it's always reproducible.

1. I can’t copy at all from SM.

2. I can apparently cut from it (since whatever text I cut disappears from the screen), but whatever I cut can’t be pasted anywhere.

3. I can cut or copy from any software and into SM, but I cannot copy at all from SM nor can I paste in it something I tried to cut or copy from it, no matter if it’s from or into the browser or mail components.

I have exactly the same setting as Lionel Raymond’s above. My Win2KPro SP4 is in French (could that make any sort of difference?). I deleted the registry entry mentioned in bug 334500 and it didn’t change a thing. Adware and spyware (or viruses, for that matter) are not involved as my whole system has been thoroughly scanned. The bug doesn't happen in Firefox 3.5.4.

The only software in the background that I could see interfering would be McAfee. How would I check for that?

Comment 7

[fwilsey]

For the record, I also use McAfee on this computer.

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #7)
> For the record, I also use McAfee on this computer.

May I then suggest to cut all Internet connections (physically, i.e. pull the plug), disable McAfee and test whether Copy works?

Comment 9

[Philip Chee]

From http://forums.mozillazine.org/viewtopic.php?p=7926215#p7926215

There has been report on other forum that "McAfee SiteAdviser Service" exactly caused this problem. Complete delete or shut down of this service may solve the issue. The person who found this resolution could solve the issue by turn the service off from "System Configuration utility (msconfig)" on the Windows.

Comment 10

[sereenie]

(In reply to comment #9)
> From http://forums.mozillazine.org/viewtopic.php?p=7926215#p7926215
> 
> There has been report on other forum that "McAfee SiteAdviser Service" exactly
> caused this problem. Complete delete or shut down of this service may solve the
> issue. The person who found this resolution could solve the issue by turn the
> service off from "System Configuration utility (msconfig)" on the Windows.


This worked for me. I had to download msconfig though as it doesn't seem to be included in Win2K. For those interested, I got it from http://www.windowsutilities.net/astuces/msconfig-pour-windows-2000.html (click on the "ici" link and put the unzipped files in C:\WINNT).

Comment 11

[Lionel Raymond]

Same result here, the msconfig edit of the services (i.e. remove McAfee SiteAdvisor Service) worked. I can now copy and paste in SeaMonkey 2.0.

Comment 12

[David E. Ross]

See Thunderbird bug #330868.

Comment 13

[fwilsey]

This worked for me too. On your advice I disabled the SiteAdvisor service in Control Panel>Administrative Tools>Services. Cut and copy are now operational. 

Thanks all for the help. I guess this will be fixed in the next point release?

Comment 14

[Philip Chee]

> I guess this will be fixed in the next point release?
This will not be fixed because we don't control the code in McAfee Site Advisor. Only McAfee knows how their code works (or doesn't work). The best we (or you) can do is to complain to McAfee that their code is interfering with other applications which is naughty of them. In fact since you are a McAfee customer but not us, a complaint from you would probably carry more weight.

Comment 15

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #13)
> This worked for me too. On your advice I disabled the SiteAdvisor service in
> Control Panel>Administrative Tools>Services. Cut and copy are now operational. 

Now we have a solution that worked for everyone who saw this and commented on this bug please mark this RESOLVED WORKSFORME (you're the reporter, that's why I ask you). Note that this has already been added to the SM 2.0 Release Notes:
<http://www.seamonkey-project.org/releases/seamonkey2.0/#issues>

Comment 16

[fwilsey]

"please mark this RESOLVED WORKSFORME"...... sorry, didn't realize that was mine to do. 

I'll be happy to bounce this to McAfee, but they might not like the tone of comment #14 ("how their code works (or doesn't work).....their code is interfering with other applications which is naughty of them"). I wouldn't either, and I am not going to get involved in a finger-pointing scenario. In the company I own, finger-pointing like that rather than working toward a solution is frowned upon, and any "attitude" towards a customer is grounds for termination. 

Have a nice day.

Comment 17

[Rene ALBERT]

Attachment: Solution to éliminate this problem with Mc Afee

I confirm the problem.
To eliminate it : 
- display McAfee folder (within Program Files)
- display folder content and find McAfee Site Advisor subfolder
- find unistall.exe McAfee Site Adviser
- execute it

After execution, it display an inquiry sceen which allows to tell McAfee with the reasons for uninstalling.

Comment 18

[psuatocobra]

As part  the "Enter a bug" process I’ve found this one, Bug 525601, to be an exact match, Other Bugs which may be dups are Bug 528083, Bug 527662, Bug 515169, and Bug 525706. 
 
Bug 525706 was marked as a dup Bug 525601, but was reopened incase it was Windows7 related.
 
Even though Bug 515169 has been closed, it may be this same problem. Same goes for Bug 527662.
 
Bug 528083 is UNCONFIRMED, but seems to be an exact match.
 
The following is a reference from earlier in Bug 525601: http://forums.mozillazine.org/viewtopic.php?p=7926215#p7926215
calls turning off or uninstalling "McAfee SiteAdviser Service" as a “resolution”. I call it a work-around.
 
 
 
In order to save time, the following is a post from me on the Google Groups, mozilla.support.seamonkey, ‘Copy & Paste’ thread,
http://groups.google.com/group/mozilla.support.seamonkey/browse_thread/thread/b2814e68c43767cb/cede7910a7ec3f85?lnk=gst&q=copy%26paste#cede7910a7ec3f85:
 
“… It seems that the consensus is that its McAfee's problem to resolve. 
But the first thing asked when a problem surfaces, is "What changed?" 
For me it's SeaMonkey (2.0). I've been running the same version of 
McAfee since 2009/09/27. This version of McAfee, Total Protection 
2010, was released to the public before SeaMonkey 2.0. SM 2.0 is the 
new one in the pool (relatively), so to speak. Generally, it's up to 
the last changer to investigate, find any problems on their side, or 
determine the problem is not theirs, Yes, I confirm that turning off 
McAfee SiteAdvisor makes the problem go away for me also. But that 
doesn't mean its McAfee's fault. Personally I don't care whose fault 
it is. Fault is not the issue, determining what caused the problem is. 
Once that's established, the ball will be in whoever's court. They 
(whoever it turns out to be) must then decide how to respond and give 
a priority to that response. 
 
A MozillaZine Forums post, http://forums.mozillazine.org/viewtopic.php?f=40&t=1558785&start=15 
, contains an interesting comment: 
 
"Look, the problem is with Seamonkey when you try to copy text out of 
it. Every other browser allows copy without problem. I am having the 
same issue. It happened as soon as my Seamonkey 2.0 beta upgraded 
itself to the release version. Also, copy was working fine in the 2.0 
beta and RC2. Same firewall, same antivirus, the only thing that 
changed was Seamonkey. Paste from non-Seamonkey apps into Seamonkey 
works fine for me." 
 
So, this poster claims that copy-&-paste worked fine in SeaMonkey 2.0 
right up until the time it went GA (IBM talk meaning "Generally 
Available"), released for production, final edition, etc. This sounds 
like key info for determining the cause. 
 
Also in that MozillaZine Forums post: 
"My final possible stupid question - who is responsible for correcting 
this glitch? In the past I have used the McAfee site advisor in IE and 
it would be annoying to switch it on and off from msconfig." 
 
I feel the same. 
 
I'm new to Google Groups mozilla.support.seamonkey . How does this get 
investigated? I'm not taking sides. I'd just like a definitive answer. 
 
Thanks, 
---P.A.C. ”
 
END OF COPY FROM http://groups.google.com/group/mozilla.support.seamonkey/browse_thread/thread/b2814e68c43767cb/cede7910a7ec3f85?lnk=gst&q=copy%26paste#cede7910a7ec3f85
 
The reply I received has brought me to this point. It was also suggested that I contact McAfee, which I also intend to do.
 
As for Bug 525601, WORKSFORME just isn’t the right Status/Resolution. 
 
Just for the record I’m running Windows XP SP3 plus all subsequent Critical Updates, freshly re-installed from scratch as of 2009/09/27.
 
Thanks, Psuatocobra or P.A.C. for short

Comment 19

[Philip Chee]

We don't have the source code to the McAfee Site Advisor so we have no idea what it is doing exactly to interfere with our cut and paste. No other program interferes with our cut and paste (except for the Yahoo security suite which is a rebranded McAfee product) so it is very unlikely that there is a problem with our code - otherwise any and every security software would be interfering. The people who have the source code to the Site Advisor are in the best position to determine how McAfee is disabling our cut and paste functionality and those people are the McAfee developers.

Phil

Comment 20

[psuatocobra]

Thanks Phil.

I understand your point.

Apparently there is no direct way to open/report a problem to/with McAfee. But there are McAfee Community discussion groups (McAfee own). 

Discussion  “Site Advisor Service conflicts with SeaMonkey 2.0”, 
http://community.mcafee.com/message/97378;jsessionid=76FDB72CAD7889DB19A81A09D9E15054.node0#97378 had already been started on Nov 7, 2009 7:02 PM, last updated Nov 9, 2009 11:09 AM. 

A couple of suggestions have been put forth, but no feedback has been provided on whether any of the actions have been taken, or the results of those actions.

I’ll keep this Bug informed on any progress on the McAfee end. (That is if Bugzilla works that way. In other words, will there come a time when this Bug is no longer updateable?)

P.A.C.

Comment 21

[Philip Chee]

You can always update any bug in bugzilla, even after it is CLOSED or RESOLVED. However eventually the utility of doing so will decrease until it isn't worthwhile any more. But as long as the McAfee issue is still affecting SeaMonkey, this bug can certainly be kept open.

Comment 22

[therube]

Just a thought ...

Per #18, it appears there /may/ be a regression range.
There is another consideration too, in that the McAfee software was changed.

So if someone with these McAfee softwares might look into these avenues.

> Also, copy was working fine in the 2.0 
beta and RC2. Same firewall, same antivirus, the only thing that 
changed was Seamonkey

That seemingly would only be partially correct as RC2 /was/is/ the release, so that may somewhat discount the regression range idea & point towards a change on McAfee's part.

Anyhow, if there is a regression in SeaMonkey, it may be able to be fixed.
Or if a software version change could be determined on the McAfee end, that could confirm the RESOLVED WORKSFORME & may help McAfee in coming up with a fix.

Comment 23

[Richie]

I am one of the original reporters of this bug. I find the following:

a) McAfee Total Protection Beta 2010 no longer allows the end user to select what applications to install. It will simply download the entire suite of products and install them.

b) McAfee Total Protection Beta 2009 allowed a custom install similar to McAfee (Comcast) Internet Security Suite, which was last updated in February 2009.

c) The bug does not occur with Norton 360 bundled with Toshiba Satellite laptops.

This would confirm the bug is related to McAfee.

I suspect, and this is my humble speculation, the reason the bug was not evident before is that end users were selecting only Virus Scan and eschewing the Site Advisor.

Unfortunately, nothing is ever perfect. To suggest users must disbale or unisntal another software application to get an existing application to work is not a great solution, but from all the comments I have read, it seems to work.

I have been running SeaMonkey since 0.9, I forget when that was released.

Thanks

Comment 24

[NoOp]

I wonder if perhaps this fix contributed to the issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=463249
[Expose anti virus and scam preferences in the MailNews Preferences UI]

Does turning on/off the scam filter change anything? I don't have McKafee to test with. In about:config it is: mail.phishing.detection.enabled and also in Edit|Preferences|Junk & Suspect Mail|Suspect Mail|'Tell me if the message I'm reading is a suspected email scam' & 'Allow antivirus clients to scan incoming messages more easily'. Don't know what the preference name is for the last.

Comment 25

[Philip Chee]

> I wonder if perhaps this fix contributed to the issue:
> https://bugzilla.mozilla.org/show_bug.cgi?id=463249
> [Expose anti virus and scam preferences in the MailNews Preferences UI]

I doubt it. The underlying functionality has always been there.

1. All this bug does is to expose a UI.
2. The Scam pref has always been on by default.
3. Thunderbird has had these two preferences exposed in their UI for ages, they have more users than we do, and McAfee Site Advisor has never been a problem for Thunderbird.

Comment 26

[psuatocobra]

Sorry I wasn't able to check back sooner. I have six comments to add, numbered 1) through 6).

1) Pursuant to Comment 20, the following was added to 
Discussion  “Site Advisor Service conflicts with SeaMonkey 2.0”, 
http://community.mcafee.com/message/97378;jsessionid=76FDB72CAD7889DB19A81A09D9E15054.node0#97378 :

" 7.  Nov 13, 2009 1:21 AM  in response to: psuatocobra
Re: Site Advisor Service conflicts with SeaMonkey 2.0

I've read through the submitted information as well as the bugzilla link and we have passed it on to engineering.  However, Ex-Brits comment of SiteAdvisor does not support SeaMonkey holds true.  If someone is trying to use SiteAdvisor with SeaMonkey then our recommendation would also be to not use SiteAdvisor with SeaMonkey and to disable it.

That being said, there is obviously something wrong going on that we need to investigate.  However we do need to have the SeaMonkey Project folks work with us as it may not be just a "McAfee issue".  The reason I say that is that users have obviously been having no problems with SiteAdvisor and SeaMonkey previous to the 2.0 release they did at the end of October.   As we hadn't released a new version at the time of the issue being reported to SeaMonkey, there is obviously something they changed in code that is different that either exposed an issue with SiteAdvisor that we've never seen before or has exposed an issue within their application that they were not aware of.

If a resolution is found we will provide an update.

Thanks"


2) Pursuant to Comment 22:
> There is another consideration too, in that the McAfee software was changed.

The "McAfee Product Information" from my installation of McAfee Total Protection 2010 says my SiteAdvisor was last changed 10/1/2009 : 
SiteAdvisor
Version: 2.9
Build 2.9.258
AffId: 0-908
Language: en-us
Last Update: 10/1/2009

3) More on Comment 22, concerning regression. Do you mean older SeaMonkey 2.0 versions? If so, which versions? The SeaMonkey Download & Releases page contains the following previously released 2.0 versions:
# 2.0 RC 2
# 2.0 RC 1
# 2.0 Beta 2
# 2.0 Beta 1
# 2.0 Alpha 3
# 2.0 Alpha 2
# 2.0 Alpha 1
Currently I have both SM 1.1.18 & the latest 2.0 installed and running (although only one at a time) on my PC. If you think it will help, I'll uninstall my 2.0, install any of the older pre-release 2.0 versions, and test against my McAfee SiteAdvsor. That is as long as doing so won't break anything (worse) for me. Please let me know of any downsides to this strategy.

4) Pursuant to Comment 23:
> a) McAfee Total Protection Beta 2010 no longer allows the end user to select
> what applications to install. It will simply download the entire suite of
> products and install them.
But, you can uninstall it by executing
C:\Program Files\McAfee\SiteAdvisor\uninstall.exe
This is per the Copy & Paste thread on mozilla.support.seamonkey | Google Groups. 
I can verify on my PC that 
C:\Program Files\McAfee\SiteAdvisor\uninstall.exe 
exists, but I haven't actually tried it.

5) More in response to Comment 23:
> This would confirm the bug is related to McAfee.
I agree with "related", but I think it may take input from both the SiteAdvisor & SeaMonkey 2.0 sides in order to pinpoint the problem.

6) More in response to Comment 23:
> ...an existing application... 
& 
> I have been running SeaMonkey since 0.9, I forget when that was released.
This problem started (for me) beginning with the final released version of SM 2.0. The problem doesn't happen with SM 1.1.18 in the same environment. I don't know about earlier 1.1.x versions. I haven't been running McAfee that long.

EXTRANEW-EXTRANEW-EXTRANEW
I' have found a better work around. 
A) Close all SeaMonkey 2.0 windows (seamonkey.exe must end or not be running).
B) Open the Services API.
C) Stop the "McAfee SiteAdvisor Service" service
D) Open/Start SeaMonkey 2.0 (copy/cut into clipboard now works)
E) As needed, Open/Start either Internet Explorer and/or Firefox ("McAfee SiteAdvisor Service" automatically restarts)
F) As long as the instance of seamonkey.exe stays up (the one that you had started while "McAfee SiteAdvisor Service" was stopped), copy/cup into clipboard will continue to work. I encountered no abnormalities when seamonkey.exe ends.
G) If IE is up before starting step A), no abnormalities were noted when ending IE, iexplore.exe .
H) If Firefox is up before starting step A), one out of three firefox.exe program ends resulted in its crashing with a "Mozilla Crash Reporter" window (the first out of three tests).
I) If seamonkey.exe should end, repeat starting at step B) to get back the copy/cut into the clipboard from SeaMonkey 2.0.
***) No re-boot required as with the msconfig work-around.

One drawback: I think Admin privileges are required for access to the Services API, but then isn't that so for accessing msconfig? 

 "Home » Development" <<<<<------ HEY, WITH THIS WORKAROUND, I JUST COPY'ED THIS FROM ANOTHER SEAMONKEY 2.0 WINDOW AND PASTED IT HERE, WHILE "McAfee SiteAdvisor Service" IS STARTED & THE SITEADVISOR ADD-ONS ARE WORKING IN IE & FIREFOX. YEAH !!!!!!!!!!!!!!!!

Comment 27

[Philip Chee]

OK I think I should reopen this so that we can track the issue.

> H) If Firefox is up before starting step A), one out of three firefox.exe
> program ends resulted in its crashing with a "Mozilla Crash Reporter" window
> (the first out of three tests).

AhaAha. A clue. In this scenario, when does Firefox crash? At step A, step B or step C. In any case you should allow the crash reporter to send a crash report to the mozilla crash-stat server. Once Firefox restarts, go to about:crashes . This will pull up a list of recent crashes. These are all hyperlinks to the mozilla crash-stat server. Copy and paste the latest link here.

> # 2.0 RC 2
> # 2.0 RC 1
> # 2.0 Beta 2
> # 2.0 Beta 1
> # 2.0 Alpha 3
> # 2.0 Alpha 2
> # 2.0 Alpha 1

The fastest way to do this is to download the ZIP builds and unpack them to a separate location. Make sure all other SeaMonkey instances are shut down, then start the seamonkey.exe from your extracted location. You can do a binary bisect by starting with Beta 1. Depending on the outcome move on the either Alpha 2 or RC1.

To further narrow down the regression range using the nightly comm-191 ZIP builds from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/.

> The "McAfee Product Information" from my installation of McAfee Total
> Protection 2010 says my SiteAdvisor was last changed 10/1/2009 : 

Yes but when did McAfee push this update to users, especially those who were on versions where the Site Advisor was optional?

Comment 28

[psuatocobra]

First Response: THE FIREFOX CRASH HAPPENED AFTER STEP C):
The exact sequence was:
1) "McAfee SiteAdvisor Service" has been started; McSACore.exe is running.
2) Open IE and verify that IE is reporting feedback from SiteAdvisor.
3) Open Fixefox and verify that Firefox is reporting feedback from SiteAdvisor.
4) Stop "McAfee SiteAdvisor Service"; McSACore.exe is no longer running.
5) Open SeaMonkey 2.0 and verify that copy/cut to Clipboard is working
6) Goto another webpage in the already open IE window, verify that "McAfee SiteAdvisor Service" has been restarted 
(McSACore.exe is running again), and verify that IE is reporting feedback from SiteAdvisor.
7) Goto another webpage in the already open Firefox window and verify that Firefox is reporting feedback from SiteAdvisor.
8) Re-verify that copy/cut is still working in SeaMonkey 2.0.
9) Close IE; iexplore.exe is no longer running.
10) Close Firefox; firefox.exe is no longer running. (Firefox crashed during its close/ending on the first pass through this sequence)
11) Close SeaMonkey 2.0; seamonkey.exe is no longer running.
***) I repeated the above sequence two more times. Firefox didn't crash again. 

Second Response: THE BAB NEWS: NO FIREFOX CRASH REPORT:
I haven't been using Firefox for long. This is the first "Mozilla Crash Reporter" window I've seen. Unfortunately, it's the only one I've seen. I can't recreate it. (I tried the exact sequence noted above in my First Response; I even tried varying the sequence a little on a couple of what was probably about a dozen re-tests/re-tries. FYI: My PC was down overnight.) And when it happened last night, I didn't send the report because it says, "Tell Mozilla about this crash so they can fix it" Fix what? I was testing a work-around by doing something abnormal, so I decided not to report it. I thought, why muddy the waters for Firefox. Now I wish I had sent the report. Anyway, about:crashes lists no "Submitted Crash Reports". BUT, I WILL SEND THE REPORT (& any & all other crash reports) ANY TIME IT HAPPENS AGAIN, AND NOTE EACH OCCURRENCE IN THIS BUG.

Third Response: ZIP BUILDS FOR # 2.0 RC 2, RC 1, Beta 2, Beta 1, Alpha 3, Alpha 2, & Alpha 1; I FOUND SOME, BUT SOME NOT FOUND:
Using the links near the bottom of "SeaMonkey: Download & Releases", http://www.seamonkey-project.org/releases/ ,
I could only find Installers for the first four. For the last three I found no Installers, but I found the following ZIP builds: seamonkey-2.0a3.en-US.win32.zip , seamonkey-2.0a2.en-US.win32.zip , & seamonkey-2.0a1.en-US.win32.zip. Are these the right ZIP files? And how do I find ZIPs for first four? Being able to test from the extracted ZIPs instead of going through a series of Uninstall/Install sequences would be a great testing time saver.
BTW: The follow mirror is not found: http://one.rz.uni-mannheim.de/pub/mirrors/mozilla.org/seamonkey/releases/2.0b1/win32/en-US/SeaMonkey Setup 2.0 Beta 1.exe

Fourth Response: WHEN DID MCAFEE PUSH THIS 10/1/2009 UPDATE TO USERS:
I'll ask if it was pushed to existing users and when, or was it/is it only available via new manual installs of SiteAdvisor or SiteAdvisor in bundles.

Comment 29

[Philip Chee]

Ah, looks like that Firefox crash was just a total coincidence then.

You can find the 2.0xY candidates here:

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/

You may have to drill down to find the zip build e.g.
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2.0b2-candidates/build1/win32/en-US/

Comment 30

[Philip Chee]

Additional information from: <http://forums.mozillazine.org/viewtopic.php?p=8020855#p8020855>

Disabling McAfee Site Advisor also fixed the following problems for this user:

===================================
- dragging tabs within the same Seamonkey window (to change the order of the tabs)
- dragging tabs between distinct Seamonkey windows
- dragging a tab from a window to the bookmarks manager (to easily place a bookmark where I'd like it to be) whether the manager is in the sidebar or standalone outside the Seamonkey window.
- can't drag an OS directory (when viewing a OS directory in the browser) to the bookmarks manager (whether the manager is in the sidebar or standalone outside the Seamonkey window).
- bookmarks (single, group, or folders) in the bookmark manager can't be dragged to different locations in the bookmark manager
- can't cut and paste bookmarks
===================================

The drag and drop code is buried deep inside the Gecko layer and written in C++ so if McAfee Site Advisor is affecting this I don't understand why it isn't also affecting Firefox 3.5.3/3.5.4

Comment 31

[psuatocobra]

Phil, I found what I needed for ZIP BUILDS FOR # 2.0 RC 2, RC 1, Beta 2, Beta 1, Alpha 3, Alpha 2, & Alpha 1. The following suggestion appeared a number times:

"The .zip files in win32/ contain a full optimized build without an installer.
If you do not understand how to get this to run, you should use installer
.exe instead."

In Comment 27 you stated:
> The fastest way to do this is to download the ZIP builds and unpack them to a
> separate location. Make sure all other SeaMonkey instances are shut down, then
> start the seamonkey.exe from your extracted location.

Do I need to do anything in addition? Just double checking.

Referencing part of your Comment 30:
> The drag and drop code is buried deep inside the Gecko layer and written in C++
> so if McAfee Site Advisor is affecting this I don't understand why it isn't
> also affecting Firefox 3.5.3/3.5.4

It makes sense that basic functionality involving Clipboard access would be deep in common Gecko code, and therefore any Firefox using that same Gecko code would be exhibiting the same behavior. 

But, my Firefox has an extra component, the SiteAdvisor Add-on, where as my SeMonkey 2.0 is naked to the SiteAdvisor in my environment. I tried removing SiteAdvsor from my Firefox Add-ons, but the SiteAdvisor Add-on Uninstall button is grayed-out, and disabling it and restarting Firefox doesn't break the copy/cut from the Clipboard. 
NOTE: I installed McAffee Total Protection 2010 before I installed Firefox 3.5.3 (now 3.5.5). The SiteAdivisor Add-on was just there from the beginning.

I could try uninstalling Firefox, msconfig disabling "McAfee SiteAdvisor Service", re-installing Firefox, make sure the SiteAdvsor extension does not appear in the Firefox Add-ons list, msconfig re-enabling "McAfee SiteAdvisor Service", re-verify that the SiteAdvsor extension still does not appear in the Firefox Add-ons list, and then try to copy&paste from Firefox. 

Before I do ALL THAT, please tell me if this line of thinking is worth following, or is it just plain BS? 

Oh! No reply to the SiteAdvisor update push question.

Thanks

Comment 32

[therube]

> Do I need to do anything in addition? Just double checking.

No.  Unzip.  Double-click seamonkey.exe.

> SeaMonkey 2.0 is naked to the SiteAdvisor

That may be correct.  I tried to "force" SiteAdvisor into SeaMonkey by adding a registry key to SiteAdvisor.

[HKEY_LOCAL_MACHINE\software\Mozilla\SeaMonkey\Extensions]
"{B7082FAA-CB62-4872-9106-E42DD88EDE45}"="E:\\Program Files\\McAfee\\SiteAdvisor"

With that, SiteAdvisor was seen by SeaMonkey. Add-on Manager reported that McAfee SiteAdvisor 3.0 was not compatible with SeaMonkey 2.01pre.  Whatever doing this may have done, it did not affect copy/paste operations for me.  (Doing only that may not have "enough" to cause things to break?)

Comment 33

[Philip Chee]

Hypothesis: the SiteAdvisor comprises two parts, [A] a separate process, and [B] a Firefox extension. In order to work both parts have to talk to each other. This problem did not exist for SeaMonkey 1.1 because it is based on older Mozilla technology and didn't look like Firefox 3.x. SeaMonkey 2.0 being based on the same backend as Firefox 3.5.3 looks sufficiently like Firefox 3.5 to the Site Advisor that part [A] tries to talk to (the missing) part [B] in SeaMonkey and when it fails the Site Advisor code goes off the rails and overwrites a part of the SeaMonkey process memory where the cut and paste and the drag and drop functionality lives. I suspect that this will also bite Thunderbird 3.0 when it is released next month. (Thunderbird 2.0 corresponds to SeaMonkey 1.1).

Comment 34

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #32)
> Add-on Manager reported that
> McAfee SiteAdvisor 3.0 was not compatible with SeaMonkey 2.01pre.

You may create a new boolean pref in about:config, named extensions.checkCompatibility, set it to false and restart SeaMonkey. The extension should be activated then (I suggest you do all that in a new profile if you haven't done so already). If copy/paste works then that would support Philip's suggestion in comment 33.

Comment 35

[psuatocobra]

I've regression tested using # 2.0 Beta 1, followed by # 2.0 Alpha 2, followed 
by # 2.0 Alpha 1, in my McAfee SiteAdvisor 2.9 (last updated 2009/10/01) environment. Copy/cut to Clipboard did not work in any of them. 
NOTE: I verified the SeaMonkey version in each test using the "About SeaMonkey" boiler plate display.

Comment 36

[Philip Chee]

2.0alpha1 dates back to 25-Sep-2008 (2008-09-25) which is more than *one* year before your McAfee SiteAdvisor 2.9 (2009/10/01). This implies that the problem started in one of McAfee's updates. Please post this information to the McAfee support forums.

Just for laughs how about testing something from
June 2008:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2008/06/2008-06-01-02-trunk/
or
January 2008:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2008/01/2008-01-01-02-trunk/

Make sure you test these on a disposable profile, since these are pre-pre-alphas.

example: seamonkey.exe -no-remote -p TempProfileName.

Phil

Comment 37

[therube]

(Oh my, I'm going to ramble ... & may have procedures, names /slightly/ wrong ...)

http://www.siteadvisor.com/download/windows.html
McAfeeSiteAdvisor:  saSetup3.0.1.152.exe

Windows 7 running as whatever a "default" user is, i.e. "standard permissions".  So you're not quite an Administator.

SiteAdvisor & SiteAdvisor alone will kill copy/paste in SeaMonkey.

McAfee Antivirus whatever or whatnot is not required.

1) install SiteAdvisor.  nothing special required.
2) start SeaMonkey.

Copy/paste is broken.
Probably more correct in saying that Copy is broken.  Nothing copied from within SeaMonkey makes it to the "clipboard".

Using Process Explorer ...
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Process Explorer -> SeaMonkey => DLLs

shows:

c:\Program Files\McAfee\SiteAdvisor\McSACorePS.dll
c:\Program Files\McAfee\SiteAdvisor\sahook.dll
c:\Program Files\McAfee\SiteAdvisor\saplugin.dll

sahook.dll contains the following (unicode) "strings":

msnmsgr.exe
mozilla.exe
chrome.exe
maxthon.exe
opera.exe
avant.exe
netscape.exe
netscp.exe
safari.exe
navigator.exe
aexplore.exe
seamonkey.exe
k-meleon.exe
flock.exe

Note the absence of string "firefox.exe".
I assume that is because firefox is handled specifically by the SiteAdvisor "extension".  (And such extension would not <normally or otherwise?> work in any of the other aforementioned browsers?)

---

In Windows Services, I have manually set McAfee (something or the other, McSACorePS.dll, I believe) to "manual", so on computer restart, copy/paste *does* work.  

After manually starting the service, & restarting the browser, copy/paste fails.

Stopping the Service does not "release" it (the hook, sahook.dll, presumably) from memory, so SeaMonkey remains affected, even after restarting the browser.

You must restart the computer.  (Or at least kill the Service <& the Process too?> & log out/then back in, which is much quicker then restarting.)

If SeaMonkey is started before starting the McAfee Service, then even though checking with Process Explorer does again show that the dll's have loaded, copy/paste remains unaffected until the browser is restarted.

Close the browser, start it backup up, & at that point copy/paste does not work.

When "restarting" the computer, (logging out then back in), you must have first stopped the service, & also have killed McSACore.exe in order for the "fix" to be effective.

If you have not stopped the service, restarting SeaMonkey restarts McSACore.exe even if you had previously killed it.

(Note that McSACore.exe shows as a Process in Process Explorer, but *not* in Windows Task Manager.)

Comment 38

[therube]

Attachment: Tracking of the saSetup3.0.1.152.exe (McAfeeSiteAdvisor) install.

Tracking of the saSetup3.0.1.152.exe (McAfeeSiteAdvisor) install.

Not everything in the install report will be relevant, but most is.

Comment 39

[therube]

Attachment: "Strings" listing of McAfee SiteAdvisor's sahook.dll file.

"Strings" listing of McAfee SiteAdvisor's sahook.dll file.

sahook.dll contains (unicode) strings of various browser names.
Absent are firefox, & IE.

Comment 40

[therube]

Attachment: Listing of the contents of saSetup3.0.1.152.exe

Listing of the (manually) extracted contents from the McAfeeSiteAdvisor installer.

Comment 41

[Philip Chee]

If you go to the add-ons manager and then to the Plugins tab do you see anything that might come from McAfee? If any of the McAfee DLLs turn up e.g. saplugin.dll try disabling them. If this works we might be able to add this to our blocklist in time for 2.0.1.

Phil

Comment 42

[therube]

There is nothing "seamonkey" extension/plugin related.

There is only McAfee sitting there with a process sitting in memory that waits, & looks for "seamonkey.exe". & once it see's that process start up, hooks itself into SeaMonkey.

Now why they do that?

And why it affects SeaMonkey's ability to copy?


Newly installed Mozilla (Gecko 1.7, circa 7-11-2006), & Google Chrome 4.0.249 & those same three dll's injected themselves into those browsers process space.

Newly installed FF35, & in there, McAfee SiteAdvisor 3.0 shows as an extension. (Two of the dll's, plus others showed up there.)

Neither Mozilla (mozilla.exe) nor Chrome nor FF35 displayed copy related problems.


(Guess I could check for a SeaMonkey 2 regression range, but that wouldn't be till tomorrow, or later.)

Comment 43

[Philip Chee]

It is possible that SA is trying to hook into SeaMonkey 1.1 and that McAfee programmers don't realize that SeaMonkey 2.0 is based on Gecko 1.9.1 and hence the backend is significantly different.

Comment 44

[psuatocobra]

Pursuant to Comment 36 :

I tested 
> January 2008:
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2008/01/2008-01-01-02-trunk/

Results are consistent; Copy/cut to Clipboard failed to work.

After failed test:
End seamonkey.exe
Stop "McAfee SiteAdvisor Service" service
Restart seamonkey.exe 2.0a1pre-2008-01-01-02-trunk; Copy/cut to Clipboard works.

A testing question: I use the same test profile for every test. If it is somehow damaged in test, can that throw off subsequent tests? Should I start with a fresh test profile per test?

Thanks

Comment 45

[Philip Chee]

I doubt it. If you are worried, create a throw away profile. In between the tests, just blow away all the files in that profile. This way you can reuse the same profile name/location.

Phil

Comment 46

[Ton [:Tonnes]]

For a while and until now, I’ve been suffering a similar problem in TB 3.0 pre-builds on both the copy and paste function as well as with toolbar customization. For this, bug 467933 and bug 502356 were opened. Interesting to see this appears to happen on Windows 2000 only, as far as I can tell.

In short: the regression range for these problems (or rather: one problem, as they seem to be related) appears to lie between 2007-10-31 and 2007-11-01. As this bug got my attention (hoping it was related), I just tried both SM 2.0 (zip) versions used for narrowing down the TB problem and guess what; copy and paste works fine on 2007-10-31, and does not when using 2007-11-01’s version. Customizing toolbars wasn’t implemented at the time so I can’t tell anything about that, but as it does not appear to work here on SM 2.0 either (!) I’m pretty sure this is not a coincidence, i.e. the issue must be more of a core problem than just anything related to McAfee, impacting both TB 3 and SM 2. In fact, there is no McAfee product on this system, and yet the problem occurs.

Please see both bugs for the time range (+ bonsai URL) and try the versions from or near those dates if you can. If this problem appears to be the same, it would be nice to see votes or comments in the bug(s) above as well - currently bug 502356 is not a TB 3 blocker, which may hopefully change for obvious reasons, or at least it would speed up a fix for TB 3.0.x.

See ftp://ftp.mozilla.org/pub/seamonkey/nightly/2007/10/2007-10-31-02-trunk/
and ftp://ftp.mozilla.org/pub/seamonkey/nightly/2007/11/2007-11-01-03-trunk/

Comment 47

[therube]

Son of a gun man!
I just came up with the same date range.  Sure wish I had refreshed this page before I started my searches!

I may be a day ahead/behind on my bonsai query.  I get confused with that.

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=2007-10-31&maxdate=2007-11-02&cvsroot=%2Fcvsroot

Anyhow, as Ton has already pointed out ...

broken:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a9pre) Gecko/2007110103 SeaMonkey/2.0a1pre

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a9pre) Gecko/2007103102 SeaMonkey/2.0a1pre

(Heh.  Wwhen i copied the build id: string "out" of the 2007110103 about: page, it failed to copy, because of the bug.)

Comment 48

[Wayne Mery (:wsmwk)]

adding times to the query is more exacting (and adding some slop hours). but i nothing looks like a good blamer to me

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=File&hours=2&date=explicit&mindate=2007-10-31+03%3A00%3A00&maxdate=2007-11-01+06%3A00%3A00&cvsroot=%2Fcvsroot

Comment 49

[therube]

Just to clarify a bit ...

When I first looked into this, I was running sandboxed (Sandboxie) on WinXP.
Installed SiteAdvisor that way.  Ran SeaMonkey that way.
Obviously I should have not done that, as my initial findings were incorrect.

Looking at it now, sandboxed, I see that the requisite dlls are not loaded in the sandbox.

My later explorations were all run natively in Windows 7.

Comment 50

[Philip Chee]

> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=File&hours=2&date=explicit&mindate=2007-10-31+03%3A00%3A00&maxdate=2007-11-01+06%3A00%3A00&cvsroot=%2Fcvsroot

@Wayne: Somewhere in there between all that Camino stuff around [2007-10-31 11:55] is Bug 386286. Looking at the CVS diff:

<http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/widget/src/windows&command=DIFF_FRAMESET&file=nsWindow.cpp&rev1=3.712&rev2=3.713&root=/cvsroot>

At the top of the code block that was removed was this comment:

////////////////////////////////////////////////////
////////////////////////////////////////////////////
// Manager for Registering and unregistering OLE
// This is needed for drag & drop & Clipboard support
////////////////////////////////////////////////////

CC: Neil: Since he reviewed that patch.

@therube: Could you try Minefield/3.0a7pre builds in that same date range?

Comment 51

[[e-mail]]

What that patch did was to change the point at which Gecko initialises OLE, which is what it uses to do copy and drag'n'drop. Originally it started up OLE when loading gkwidget.dll and shut down OLE when unloading gkwidget.dll but this lead to the hang reported in the bug, so now it starts up OLE when creating the first window and shuts it down when destroying the last window. This shouldn't make any difference but maybe SiteAdvisor is doing something interesting with OLE that is conflicting with SeaMonkey.

Comment 52

[therube]

Minefield/3.0a9pre, perhaps?
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a9pre) Gecko/2007103103 Minefield/3.0a9pre
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a9pre) Gecko/2007110103 Minefield/3.0a9pre

No matter what I did, I couldn't seem to get FF to falter.

Ran FF directly.
Renamed "firefox.exe" to "seamonkey.exe".
Renamed the Windows Registry HKLM \Firefox\Extensions key.
Hacked sahook.dll, s/seamonkey.exe/firefox.exe  /

I did get various (McAfee) dll's to load or not.
I did get SiteAdvisor plugin "removed" from FF or not.

I could not get FF to falter.

Note that when the McAfee SiteAdvisor Service is running, sahook.dll gets injected everywhere, into everything.  Though it (seemingly) actually only does something to a few select programs (processes).

Once I hacked sahook.dll (s/seamonkey.exe/firefox.exe  /), that effectively nullified any interaction with SeaMonkey.  So when SeaMonkey was run, only sahook.dll showed in its process space.  (Which would seem normal, per the paragraph above.)  With sahook.dll neutered to seamonkey.exe, neither McSACorePS.dll nor saplugin.dll ran in seamonkey.exe process space.  SeaMonkey was then unaffected.

Comment 53

[therube]

Attachment: Process Listing - firefox.exe renamed to seamonkey.exe

Comment 54

[therube]

Attachment: Process Listing - firefox.exe renamed to seamonkey.exe

This time, SiteAdvisor /extension/ is disabled from within FF itself.
Note the change in dll's loaded.

Comment 55

[therube]

Attachment: Process Listing - firefox.exe renamed to firefox.exe

SiteAdvisor extension enabled in FF.
Note the dll's loaded.

Comment 56

[therube]

Attachment: Process Listing - firefox.exe renamed to firefox.exe

Now with the SiteAdvisor extension disabled from within FF.

Note the dearth of McAfee dll's.

Comment 57

[Philip Chee]

@ Ton

> pretty sure this is not a coincidence, i.e. the issue must be more of a core
> problem than just anything related to McAfee, impacting both TB 3 and SM 2. In
> fact, there is no McAfee product on this system, and yet the problem occurs.

Hmm. But the problem in SM occurs only when McAfee Site Advisor is running.

Do you have some security software that is rebranded McAfee, or
a Toolbar like the Yahoo Toolbar, some versions of which come with the SiteAdvisor.

See if sahook.dll, McSACorePS.dll and/or saplugin.dll are present on your system.

Comment 58

[Serge Gautherie (:sgautherie)]

(Fwiw, would it make a difference that FF is --enable-libxul whereas SM is not? (iirc))

Comment 59

[therube]

> did you try renaming seamonkey to firefox

Renamed seamonkey.exe to firefox.exe.

With that 2007110103 copy/paste works as expected.

sahook.dll is loaded in the process space, but per above that would be normal as it loads everywhere.

Though McSACorePS.dll and saplugin.dll are no longer loaded into the SeaMonkey process space.  And copy/paste does work.

So sahook.dll is a listener.  When it finds its' mark, it spawns the other two processes.

Further, I again added back in:

[HKEY_LOCAL_MACHINE\software\Mozilla\SeaMonkey\Extensions]
"{B7082FAA-CB62-4872-9106-E42DD88EDE45}"="E:\\Program
Files\\McAfee\\SiteAdvisor"

but that seemed to have no affect on anything.

Comment 60

[Philip Chee]

> (Fwiw, would it make a difference that FF is --enable-libxul whereas SM is not?
But was Firefox --enable-libxul in 2007-11?

Comment 61

[Richie]

I read in the recent bundle of comments on this bug, that SiteAdvisor uses an extension for Firefox, and the comment observed that SiteAdvisor thinks seamonkley.exe is firefox.exe and then crashes when trying to "talk" to Seamonkey. If this is the case, could not the user agent string be modified to "tell" SiteAdvisor that Seamonkey is in fact Seamonkey 1.1.x and not Firefox? In this way SiteAdvisor will leave Seamonkey alone and the copy/paste will work.

Comment 62

[Philip Chee]

@Richie: That was just speculation on my part before more recent evidence that Site Advisor is actually looking for seamonkey.exe.

Comment 63

[Ton [:Tonnes]]

(In reply to comment #57)
> 
> Hmm. But the problem in SM occurs only when McAfee Site Advisor is running.
> 
> Do you have some security software that is rebranded McAfee, or
> a Toolbar like the Yahoo Toolbar, some versions of which come with the
> SiteAdvisor.

None of them at all. Basically I use the system for l10n tasks only, so it only runs a SW firewall (Kerio 2.1.5), blackhole proxy 1.0.0.5 and some editors when needed. I just disabled all, tried a current TB 3 with nothing else loaded, and yet the problem is there.

> See if sahook.dll, McSACorePS.dll and/or saplugin.dll are present on your
> system.

None of them exist, and thus are not loaded…

(In reply to comment #60)
> > (Fwiw, would it make a difference that FF is --enable-libxul whereas SM is not?
> But was Firefox --enable-libxul in 2007-11?

That’s an interesting question, I was wondering and asked the same in bug 467933 comment 5, bu no-one answered that yet.

FWIW: I have never seen this problem occur in FF 3.5, previous or later builds.

Comment 64

[Ton [:Tonnes]]

I forgot to ask: do all users suffering the copy/past problem in SM 2 experience the toolbar customization issue as well?

Comment 65

[therube]

Ah, very good question.

Well, SiteAdvisor does break toolbar customization in SeaMonkey 2.0 Release too, in both the browser & SeaMonkey Mail.

There was no such customization in SeaMonkey back in 2007.

So I downloading TB, 20071031 & 20071101.
Running as is, SiteAdvisor did not affect toolbar customization in TB.
sahook.dll did attach itself to the TB process, as expected.
But as "thunderbird.exe" is not something that sahook.dll looks for, it makes sense that it was not affected.

But, once I renamed "thunderbird.exe" to "seamonkey.exe", then SiteAdivsor *did* affect TB.  Then looking at the "seamonkey.exe" (TB) process showed that in addition to sahook.dll, McSACorePS.dll and saplugin.dll were also loaded into the process space (again as expected).

The same date ranges came into play (& this is in Windows 7).

TB 20071031 was unaffected.
TB 20071101 was affected.

So presumably whatever it is in McAfee that is triggering this in SeaMonkey, there must be something similar triggering it for you in Win2K & TB.

You have to assume that it is not solely a Win2K issue.  It is just that when others have checked, they did not have the triggering mechanism, & so aren't seeing what you are seeing.  So find the trigger.  Use Process Explorer to look for something odd that may have injected itself into TBs process space.

Comment 66

[therube]

Booting into (Windows) Safe Mode may be a quick method to see if your issue goes away.

Comment 67

[Ton [:Tonnes]]

Thanks very much, it looks like we’re getting there.

Using Process Explorer, it turned out that Matrox Pdesk, Cthelper and TortoiseHg 0.5 (with Mercurial-1.0.2, Python-2.5.1, PyGTK-2.0.16, GTK-2.10.11) are software elements I did not take into account so far. Unloading Matrox Pdesk as well as Creative files did not make a difference, and neither did using Windows safe mode. Renaming the Tortoise Program files folder and rebooting in order to not load its background files made a recent TB build work as expected though, both for copy/paste and customizing the toolbar functions. Nice to see this is possible after all. ;)

Comparing PE’s file list for both scenarios (that is, when loading Tortoise background files normally, and not), it looked like the following files are used when loaded:

* Tortoise files:
_hashlib.pyd, _socket.pyd, _ssl.pyd, base85.pyd, bdiff.pyd, bz2.pyd, diffhelpers.pyd, mpatch.pyd, PYTHON25.DLL, tortoisehg.dll, pythoncom25.dll 2.5.211.0, pywintypes25.dll 2.5.211.0, shell.pyd 2.5.211.0, win32api.pyd 2.5.211.0, win32event.pyd 2.5.211.0, win32file.pyd 2.5.211.0, win32gui.pyd 2.5.211.0, win32net.pyd 2.5.211.0, win32process.pyd 2.5.211.0, win32trace.pyd 2.5.211.0, win32ui.pyd 2.5.211.0

* MS files:
netmsg.dll DLL-bestand voor Net-berichten Microsoft Corporation 5.0.2137.1
MFC71.DLL MFCDLL Shared Library - Retail Version Microsoft Corporation 7.10.6030.0
MSWSOCK.dll Microsoft WinSock Extension APIs Microsoft Corporation 5.0.2195.7158
MSVCR71.dll Microsoft® C Runtime Library Microsoft Corporation 7.10.3052.4
Psapi.dll Process Status Helper Microsoft Corporation 5.0.2134.1
sfcfiles.dll Windows 2000 System File Checker Microsoft Corporation 5.0.2195.7038
sfc.dll Windows Bestandsbeveiliging Microsoft Corporation 5.0.2195.6673

Note that MFC71.DLL resides in the Tortoise dir, and MSVCR71.dll in both Tortoise and system32 dir. Also TortoiseOverlays.dll is loaded in both scenarios, as it resides in /common files.

To cut a long story short: it appears to be tortoisehg.dll spoiling the game. This file is used for the Windows shell extension in Tortoise 0.5, currently being a bit obsolete - its current v0.9 no longer uses it, as it was replaced by ThgShell.dll. Renaming tortoisehg.dll only and starting TB 3pre and/or SM 2 enables both functions, renaming it afterwards enables the shell extension without breaking them. However, the same thing happens when renaming pythoncom25.dll or pywintypes25.dll, while renaming pyton25.dll makes TB not start at all. In any case, I’d say this would look like it’s a Python related problem, and probably not W2K only. I’ll shortly upgrade Tortoise and see what happens on 0.9 which now uses a higher Python version. Curious as I am, it would be nice to pinpoint the versions that start and stop the breakage, though that would probably need installation of a number of Tortoise versions. Does Python in any way relate to nshook or other dll’s? And of course, why did this start at 20071101?

Comment 68

[therube]

I'll just throw something out, DLL Hell.

Looking (for other reasons) at sqlite3.dll, I find many versions in many places.
SeaMonkey, FF, /SiteAdvisor/, Spybot, & I believe /Python/ too all use (various) versions of sqlite3.dll.  (Now sqlite3.dll would not have played any part in SeaMonkey back then ...)

Also, static vs. dynamically linked DLL's ...  Perhaps on 11-01-20007 ... ?

Idea being, if not sqlite3.dll, perhaps some other?

Comment 69

[[e-mail]]

I tried installing SeaMonkey 2.0 on to a PC with SiteAdvisor on it (latest version, I think) but copy and paste worked fine for me. Maybe if I can find a piece of software that definitely conflicts with SeaMonkey then I can debug...

Comment 70

[Serge Gautherie (:sgautherie)]

(In reply to comment #67)

> TortoiseHg 0.5 (with Mercurial-1.0.2, Python-2.5.1, PyGTK-2.0.16, GTK-2.10.11)

(Oh, that one is outdated, no?)

> Renaming the Tortoise Program files folder and [...]

That was bug 443331!

Comment 71

[Philip Chee]

>> Renaming the Tortoise Program files folder and [...]
> That was bug 443331!

The root cause of that bug was mismatched DLL versions. TortoiseHg was putting it's libraries in the system path. Is it possible that when Site Advisor injects itself into the SeaMonkey process space, it hooks in a different version of a DLL than the version SeaMonkey is compiled against?

Comment 72

[therube]

The earlier version of SiteAdvisor, (the version I had tested with) is available directly from McAfee (by just changing the URL):

http://sadownload.mcafee.com/products/SA/IE/upgrade/3.0.1/website/saSetup3.0.1.152.exe

MD5: 760603b1b22641a3b03acd0b85fd7978


(Also note that if you were to visit the http://www.siteadvisor.com/download/windows.html page without having spoofed the UA, all you get is some dumb message :frown:.)

Comment 73

[[e-mail]]

With SiteAdviser installed, ::OleInitialise fails with CO_E_OLE1DDE_DISABLED...

Comment 74

[[e-mail]]

Eww, this is ugly:

ole32!CoInitializeEx
saPlugin+0xdabb
saPlugin+0x132ce
ntdll!LdrpCallInitRoutine+0x14
ntdll!LdrpRunInitializeRoutines+0x344
ntdll!LdrpLoadDll+0x3e5
ntdll!LdrLoadDll+0x230
kernel32!LoadLibraryExW+0x18e
kernel32!LoadLibraryW+0x11
saHook!saHooker_Uninitialize+0x16e
saHook!saHooker_Uninitialize+0x198
saHook!saHooker_Uninitialize+0x585
USER32!DispatchHookW+0x31
USER32!__fnHkINLPCBTCREATESTRUCT+0x82
ntdll!KiUserCallbackDispatcher+0x13
USER32!NtUserCreateWindowEx+0xc
USER32!_CreateWindowEx+0x1ed
USER32!CreateWindowExW+0x33
ole32!InitMainThreadWnd+0x3c
ole32!wCoInitializeEx+0x94
ole32!CoInitializeEx+0x112
SHELL32!SHCoInitialize+0x9
SHELL32!_CreateFolderIDList+0xeb
SHELL32!_GetFolderIDListCached+0x84
SHELL32!SHGetFolderLocation+0x9e
SHELL32!SHGetSpecialFolderLocation+0x17
xul!GetShellFolderPath+0x68
xul!nsXREDirProvider::GetUserDataDirectoryHome+0x67
xul!nsXREDirProvider::GetUserDataDirectory+0x2f
xul!nsXREDirProvider::GetUserAppDataDirectory+0xe
xul!nsToolkitProfileService::Init+0x61
xul!NS_NewToolkitProfileService+0x48
xul!SelectProfile+0x453
xul!XRE_main+0xf51
seamonkey!NS_internal_main+0x10c
seamonkey!wmain+0x106
seamonkey!wmainCRTStartup+0x12c
kernel32!BaseProcessStart+0x23

Unlike SHELL32, saPlugin never calls CoUninitialize :-(

Comment 75

[[e-mail]]

But that's not it, because simply restoring ::OleInitialize to gkwidget's DllMain "fixes" the issue, even though it happens after saPlugin's call...

Comment 76

[[e-mail]]

Attachment: Possible patch

OK, so I'm not 100% sure that this does the right thing, but it moves the Ole calls much nearer to the time when they were previously called; widget gets initialised fairly early on in startup and this seems to be early enough to stop saPlugin.dll or whatever it is from causing the problem.

And there are bound to be code issues, since this is just proof of concept.

Comment 77

[Jim Mathies [:jimm]]

So that init call will only get called once on the module initialization? (looks like it also fixes a bug in nsWindow where we init multiple times!) Generally looks safe to me.

Comment 78

[[e-mail]]

(In reply to comment #72)
> The earlier version of SiteAdvisor, (the version I had tested with) is
> available directly from McAfee (by just changing the URL):
> 
> http://sadownload.mcafee.com/products/SA/IE/upgrade/3.0.1/website/saSetup3.0.1.152.exe
I've just noticed that my version of SiteAdvisor has apparently updated itself to version 3.0.1.159 on the 23rd of December, and this version apparently does not conflict with SeaMonkey. Can anyone else verify that?

Comment 79

[erpman1]

(In reply to comment #78)
> (In reply to comment #72)
> > The earlier version of SiteAdvisor, (the version I had tested with) is
> > available directly from McAfee (by just changing the URL):
> > 
> > http://sadownload.mcafee.com/products/SA/IE/upgrade/3.0.1/website/saSetup3.0.1.152.exe
> I've just noticed that my version of SiteAdvisor has apparently updated itself
> to version 3.0.1.159 on the 23rd of December, and this version apparently does
> not conflict with SeaMonkey. Can anyone else verify that?

though the latest version of Mcafee SiteAdvisor is now 3.0.1.163 which I've just downloaded.  I'll try this one out on my other XP computer that has SM 2.0 and see if the "copy and cut" bug occurs or not.

Comment 80

[erpman1]

ok, bug seems to have gone away when installing SiteAdvisor 3.0.1.163.  I CAN copy certain text from SM 2.0.2 and the Paste option is no longer grayed out when pasting the text into SM's Composer app.

in short, upgrade McAfee SiteAdvisor to the latest release available.  Here's the link to the current version I got:
http://sadownload.mcafee.com/products/SA/IE/upgrade/3.0.1/website/saSetup3.0.1.163.exe

I'll wait for the "status" of this bug to be changed.

Comment 81

[Philip Chee]

<http://forums.mozillazine.org/viewtopic.php?p=8556575#p8556575>

Someone in the Mozillazine forums confirms that updating to the latest McAfee Site Advisor fixes the copy/cut/paste problem.

Comment 82

[Robert Kaiser]

Philip, this is good to hear!

Neil, should we still look into taking your patch or should we drop the matter?

Comment 83

[[e-mail]]

I don't think we should try to take the fix if we don't need to.

Comment 84

[erpman1]

not so fast, Philip Chee, Robert Kaiser and Neil!

Please read the following mozillazine forum thread:
http://forums.mozillazine.org/viewtopic.php?f=40&t=1602485

quote from a "Guest" user:
"That can't be the only reason. I have the same problem, but do not use Site Advisor with SeaMonkey. I can copy text strings from other programs and paste into SeaMonkey, but can't copy and paste anything from SeaMonkey into SeaMonkey! This problem makes SeaMonkey almost useless to me for updating web pages."

Comment 85

[[e-mail]]

This bug quickly became specific to SiteAdvisor. People still having the issue would first have to discover which third-party software is causing the conflict. One way to do this is to use the WinDbg debugger, see https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg for some background information. In this case, before running SeaMonkey, you need to issue the command bp ole32!CoInitializeEx which will tell WinDbg to stop whenever someone tries to set up COM. See comment 74 which actually shows two calls to CoInitializeEx in one stack. As it happens the one issued by saPlugin is never uninitialised and this is what causes the conflict with SeaMonkey, but you don't need to know that, all you need to note down is the module on the second line for each call (of course some modules are expected e.g. SHELL32).

Comment 86

[Robert Kaiser]

Note that _using_ SiteAdvisor with SeaMonkey is no factor at all for it, having SiteAdvisor installed is enough to see the problem, even if you set it to not be used with SeaMonkey.
And if SiteAdvisor is installed at all, then installing the newest version should make the problem go away.

Comment 87

[Ton [:Tonnes]]

I agree on comment 84. As commented above, there are more products (or their dll’s) that trigger the issue both in TB and SM - McAfee Site Advisor is just one example, Tortoise is another one (yes, having it installed only on a pretty ‘empty’ system for l10n purposes is enough), and presumably there must be plenty of others. I.o.w., if this is not fixed (or rather, left as it is) on Mozilla’s side, chances are some other product may trigger the issue as well some day or possibly does so already.
I’d suggest taking a fresh look at the regression range given and trying to find the exact cause. There has to be a clear reason that either resides in trunk changes or compiler options. I just wish it had been reported in november 2007, but wonder what would have happened then. ;)

Comment 88

[erpman1]

Ton makes a very good point.  What version of Tortoise were you using that caused Seamonkey's copy/cut features to not work properly?  Try installing different versions (including the latest version available) of Tortoise and see if the problem occurs or not.

well, Neil and Robert, Ton has spoken.

Comment 89

[Ton [:Tonnes]]

Erpman1: see comment 67 - it’s Tortoise 0.5 that triggers the problem as well.

As written there, I was about to upgrade Tortoise to see if the problem is still present, but as I’m pretty sure it won’t (and would rather see this fixed instead of working around the problem), I prefer to keep 0.5 in order to verify if the problem was fixed.

Comment 90

[Philip Chee]

The patch in Comment 76 is rather scary with unknown side effects. We'd rather other applications either not hook into our process space, or do it properly.

Comment 91

[[e-mail]]

I installed something calling itself "TortoiseHg 0.5" on my computer, but copy and paste still worked. Did I install the wrong application?

Comment 92

[erpman1]

(In reply to comment #89)
> Erpman1: see comment 67 - it’s Tortoise 0.5 that triggers the problem as well.
> 

are you absolutely sure?  then why is Neil getting a different result on his machine?  why does copy/paste still work with TortoiseHg 0.5 and SM 2.x on Neil's computer and not yours, Ton?  is it a different Tortoise app that you were using than what Neil had installed?

it seems this copy/cut/paste bug is starting to become more confusing.  one user encounters the problem with copy/paste & Tortoise and the other user does not.

Comment 93

[Philip Chee]

Hello. This bug has been narrowed down to McAfee. If you still have a problem with TortoiseHg then please file a NEW bug. However given that even for the person with that problem can't reproduce it with a newer version of TortoiseHg (Current version is 0.9.2. Also I have been using this since 0.5 myself and I've never seen this cut and paste problem.

Comment 94

[Ton [:Tonnes]]

Erpman/Neil: it’s TortoiseHg 0.5 indeed, but on Win 2000 SP4 RP1 (v2). Did you happen to use XP? I’m not sure if enabling shell extension for Tortoise makes a difference, but if it wasn’t, "regsvr32 "C:\\Program Files\\TortoiseHg\\tortoisehg.dll" " should enable it. If I rename the dll, the shell integration is gone.
There is also an item called Python Trace Collector in Tortoise’s startup menu that may indicate tortoisehg.dll. The dll version here is unknown but sized 20.992 bytes, dated 2008-09-28. As said, the problem may be related to Python, so may be there is another Python version on your system? And in what way does McAfee relate to Python?

Philip: I agree this bug may be or at least look like the problem was narrowed down to McAfee, but clearly that’s not the only product triggering the ‘vulnerability’, as we may call it. If you disagree on using this bug to find the _exact_ cause, that’s fine with me though, but that would mean bug 502356 needs to be renamed (or filing a new one in which Python is a presumable suspect) and the discussion/investigation will probably continue there…

Comment 95

[Philip Chee]

The McAfee problem does not affect Thunderbird so that is a different problem. I'll change the summary of this bug to reflect the final focus.

Comment 96

[erpman1]

(In reply to comment #94)
> Erpman/Neil: it’s TortoiseHg 0.5 indeed, but on Win 2000 SP4 RP1 (v2). Did you
> happen to use XP? I’m not sure if enabling shell extension for Tortoise makes a
> difference, but if it wasn’t, "regsvr32 "C:\\Program
> Files\\TortoiseHg\\tortoisehg.dll" " should enable it. If I rename the dll, the
> shell integration is gone.
> There is also an item called Python Trace Collector in Tortoise’s startup menu
> that may indicate tortoisehg.dll. The dll version here is unknown but sized
> 20.992 bytes, dated 2008-09-28. As said, the problem may be related to Python,
> so may be there is another Python version on your system? And in what way does
> McAfee relate to Python?
> 

Ok folks.  I have attempted to reproduce the copy/paste problem with TortoiseHG 0.5, SeamonkeyM 2.0 and on three different machines.  One using Win2000, the two others XP and Vista.  From my tests, I've found out the problem Ton is experiencing DOES occur under Win2000.  On the XP and Vista computers, the problem does NOT happen.  So "that" copy/paste bug only happens under Win2000 and NOT XP and higher. 

I would definitely suggest filing a new bug if TortoiseHg 0.5 causes copy/paste problems in SM 2.0 BUT only under Win2000.

Comment 97

[[e-mail]]

Reproduced with TortoiseHg 0.5 on Windows 2000.

I don't know why installing these applications causes the problem, but I now have a new workaround coming up.

Comment 98

[[e-mail]]

Attachment: Possible patch [Checkin: Comment 106]

This fixes it for me, but I'm not quite sure why...

Comment 99

[David :Bienvenu]

Comment on attachment 425107 [details] [diff] [review]
Possible patch
[Checkin: Comment 106]

This looks reasonable - however, MAPI is not working on my machine, with our without this patch, so I can't test it per se, so I'd want someone to be able to test it on Windows with TB before landing (I don't see how we could write a unit test for this)

Comment 100

[David :Bienvenu]

I did look on MSDN, and the change seems reasonable from what I read about the API's.

Comment 101

[erpman1]

(In reply to comment #97)
> Reproduced with TortoiseHg 0.5 on Windows 2000.
> 
> I don't know why installing these applications causes the problem, but I now
> have a new workaround coming up.

now try reproducing the problem with TortoiseHg version 0.9 and Seamonkey 2.0.2 under Win2000, Neil.  I did such a thing on my relative's W2k computer and the copy/paste problem seems to have gone away.

Comment 102

[Serge Gautherie (:sgautherie)]

Reminder about TortoiseHg 0.5 + Windows 2000:

(In reply to comment #70)
> That was bug 443331!

Comment 103

[Serge Gautherie (:sgautherie)]

(In reply to comment #99)
> I'd want someone to be able to test it on Windows with TB before landing

Make Try builds available?

Comment 104

[[e-mail]]

(In reply to comment #103)
> Make Try builds available?
http://s3.mozillamessaging.com/build/try-server/2010-02-04_02:[e-mail]-neil-525601/[e-mail]
http://s3.mozillamessaging.com/build/try-server/2010-02-04_02:[e-mail]-neil-525601/[e-mail]

Comment 105

[Ton [:Tonnes]]

Erpman: happy to see your test results on w2k, thanks. I haven’t tried any 0.5+ version yet, but am convinced that should work fine.

Serge: thanks for the (2nd) bug 443331 reminder. In fact I’d say TB bug 502356 is a dupe indeed, though I was convinced that renaming library.zip instead of tortoisehg.dll did not fix it for me earlier, but apparently it does.

Neil: appreciating your fix, I used the Try build on W2K and copy/paste as well as toolbar customization works fine with THg 0.5.

Comment 106

[[e-mail]]

Pushed changeset c1f641cb342e to comm-central.

Comment 107

[[e-mail]]

Comment on attachment 425107 [details] [diff] [review]
Possible patch
[Checkin: Comment 106]

Since this bug affects TB3.x too (although it's worse with SM2.x), this seems like a safe enough fix to take on the branch.

Comment 108

[Serge Gautherie (:sgautherie)]

V.Fixed, per comment 105.

Comment 109

[erpman1]

(In reply to comment #105)
> Erpman: happy to see your test results on w2k, thanks. I haven’t tried any 0.5+
> version yet, but am convinced that should work fine.
> 
> Serge: thanks for the (2nd) bug 443331 reminder. In fact I’d say TB bug 502356
> is a dupe indeed, though I was convinced that renaming library.zip instead of
> tortoisehg.dll did not fix it for me earlier, but apparently it does.
> 
> Neil: appreciating your fix, I used the Try build on W2K and copy/paste as well
> as toolbar customization works fine with THg 0.5.

but DO consider upgrading THg to version 0.8 or better on your W2k machine.  as Serge said in bug 443331, problem has also been fixed on THg's end starting with v0.8.

Comment 110

[Ton [:Tonnes]]

(In reply to comment #109)
> but DO consider upgrading THg to version 0.8 or better on your W2k machine.

Of course. 0.5 was mainly kept for this bug’s testing purposes (and to a lesser extent, in case 0.8 does not work well on W2k).

(In reply to comment #106)
> Pushed changeset c1f641cb342e to comm-central.

Will (or could) this be pushed to comm-central-1.9.1 as well?

Btw thanks everyone for the input and thinking along.

Comment 111

[[e-mail]]

(In reply to comment #110)
> (In reply to comment #106)
> > Pushed changeset c1f641cb342e to comm-central.
> Will (or could) this be pushed to comm-central-1.9.1 as well?
You overlooked comment #107 ;-)

Comment 112

[Mark Banner (:standard8)]

Comment on attachment 425107 [details] [diff] [review]
Possible patch
[Checkin: Comment 106]

a=Standard8

Given that we've had some ok responses from the try server build testing, I'm happy to short-cycle getting this onto 1.9.1 especially as it'll get some extra testing ;-) (it is also a low risk ish patch as it is well-focussed to a specific area).

Comment 113

[Robert Kaiser]

Neil, please check in on 1.9.1 ASAP so we can start 2.0.3 builds. Thanks.

Comment 114

[[e-mail]]

Pushed changeset 8289e10542da to releases/comm-1.9.1

Comment 115

[erpman1]

(In reply to comment #110)

> Of course. 0.5 was mainly kept for this bug’s testing purposes (and to a lesser
> extent, in case 0.8 does not work well on W2k).
> 

other older versions of TortoiseHg (0.73 and earlier such as 0.6, 0.7, even much older versions like 0.3 & 0.4, etc.) also compound the copy/paste problem in SM 2.0 & Win2k, Ton.  I even tried THg v0.7 on the Win2k SP4 machine with SM 2.0.2.  same result as with THg 0.5 you experienced.

anyways the problem has now been fixed on both SM's and THg's ends.  a test candidate build of SM 2.0.3 for Win2k is available here:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2.0.3-candidates/build1/win32/
if all goes well, then this build will be the official release of SM 2.0.3 coming mid-February.  I'll install that one ASAP.