360101 - When these 5 Acrobat processes remain after viewing a PDF in SeaMonkey, PDF files will not display -blank page- in SeaMonkey after restart

Status: VERIFIED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Olivier Vit (just a reporter)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.9a1) Gecko/20061017 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.9a1) Gecko/20061017 SeaMonkey/1.5a

For a while I'm having a lot of trouble with the Acrobat Plugin.
I had a look at most of bug 336184 related ones, but couldn't find a true dup.

I had been running the latest of Acrobat Pro 6.0.x series
I'm now running Acrobat Pro 7.0.8 with the same trouble.



Reproducible: Sometimes

Steps to Reproduce:
1. Start SeaMonkey
2. Browse some web sites, open PDF files in the browser (preferably not present in cache)
3. Quit SeaMonkey
4. Look at taskmanager 

Actual Results:  
Acrobat.exe (pro version) is still running as a process, but no visible window
And two Adobelm_Cleanup processes are running

If you restart SeaMonkey, redo steps 1-2, usually PDF files will not display in the browser, and usually will lock the application (nothing can be performed, but the taskmanager doesn't show the SeaMonkey application as not responding)

It is needed to kill the Acrobat.exe process to recover the display of PDF files

Expected Results:  
Quit properly Acrobat.exe when this one is not opened outside of SeaMonkey.
Display PDF files.

Plugin version
Adobe Acrobat

    File name: D:\Program Files\Adobe\Acrobat 7.0\Acrobat\browser\nppdf32.dll
    Adobe Acrobat Plug-In Version 7.00 for Netscape

MIME Type 	Description 	Suffixes 	Enabled
application/pdf 	Acrobat Portable Document Format 	pdf 	Yes
application/vnd.fdf 	Acrobat Forms Data Format 	fdf 	Yes
application/vnd.adobe.xfdf 	XML Version of Acrobat Forms Data Format 	xfdf 	Yes
application/vnd.adobe.xdp+xml 	Acrobat XML Data Package 	xdp 	Yes
application/vnd.adobe.xfd+xml 	Adobe FormFlow99 Data File 	xfd 	Yes

I also suspect this to affect memory usage (I often reach 600Mbytes of virtual memory usage after HALF a day of usage of SeaMonkey with heavily animated Flash content) and to be related to plugins in general since I experience other plugin hangs : see bug 359739

Comment 1

[Olivier Vit (just a reporter)]

Attachment: running acrobat processes when Acrobat files are not being displayed anymore

Comment 2

[Olivier Vit (just a reporter)]

After exiting SeaMonkey, it is not possible anymore to launch the standalone Acrobat Pro windows application either.

Comment 3

[Gérard Talbot]

In no way this bug severity is major.

Acrobat process remaining in task bar is a feature. Remaining process will also happen like that in other browsers too.



*** This bug has been marked as a duplicate of 167165 ***

Comment 4

[Olivier Vit (just a reporter)]

And not showing the PDF files after restart is also a feature ?
Not being able to start the windows application is also a feature ?

Comment 5

[Olivier Vit (just a reporter)]

The two Adobelm_Cleanup processes don't remain either when using MS IE for example

Comment 6

[Olivier Vit (just a reporter)]

(updated the summary to focus on the issue)

Adobe Acrobat processes seem unable to properly be released from SeaMonkey after loading PDF files within SeaMonkey, closing the PDF window, browsing other pages, possibly when other plugin contents are being displayed (like Flash, player version 9 r16), closing SeaMonkey.

When these processes remain, it will not be possible anymore to open the standalone Acrobat application nor PDF files within a restarted SeaMonkey application:
Acrobat.exe
acrotray.exe
Adobelm_Cleanup
Adobelm_Cleanup
Adobelmsvc.exe

Comment 7

[Gérard Talbot]

Olivier, 

you changed the summary where your original description of the problem was clearly identified as the Adobe Acrobat Reader process remaining. 

The phenomenon is entirely between Adobe and your operating system: Mozilla has nothing to do with this. 
Whenever you say "kill the Acrobat.exe process", "still running", "launch the standalone Acrobat", "not showing the PDF files after restart", "being able to start the windows application", etc.., you're referring to software interaction between the application (Acrobat Reader AcroRd32.exe) and your operating system. I repeat: Mozilla has nothing to do with this and is not involved in these issues. Acrobat.exe, acrotray.exe, Adobelm_Cleanup, Adobelm_Cleanup, Adobelmsvc.exe are not processes generated/controlled by Mozilla Seamonkey and have not been written by Mozilla developers as far as I know.

Finally, you believe this is a *major* _Mozilla_ bug? I do not. 
It could well be a major Adobe Acrobat bug though.

If you see/have more than 1 issues, then you should open separate bug reports for each of them. Your description should be about 1 issue: 1 issue only for 1 bug.

I still believel this bug report should be resolved as a duplicate of bug 167165

Regards, Gérard

Comment 8

[Olivier Vit (just a reporter)]

Still trying to better understand the issue and clarifying the description of this bug (yes I updated again the summary):
This behavior only happens after having used Mozilla SeaMonkey, and affects the ability of SeaMonkey to open PDF files after a restart of SeaMonkey (I'm sure there has been a bunch of bugs describing situations where PDF sometimes didn't open in Mozilla, I'm trying to narrow down on this).
This is why I believe this is a seaMonkey bug.
It has been occuring with multiple versions of Acrobat 6.0.x and 7.0.x and raised only with a release of SeaMonkey (but probably 5-6 months ago and until now I thought I had something wrong: after upgrading to 7.0.8 and since Flash player 9 is out, I don't see any other option than reporting this bug)

Gerard, OK it is not major, and thanks for your help in focusing on the core of the issue.

Comment 9

[Gérard Talbot]

> This behavior only happens after having used Mozilla SeaMonkey

Which behavior exactly? Because you are mentioning several behaviors. I do know that process remaining (AcroRd32.exe) is not specific to Seamonkey: it happens in other browsers as well and such behavior is a feature, an Adobe feature.
Process remaining in memory and re-initializing the Adobe Acrobat Reader application are 2 distinct Acrobat issues, not 2 Mozilla bugs. 

Management of the 5 processes you refer to are done by the operating system; those 5 processes you refer to are not coded/developed by Mozilla developers but by Adobe software developers. Please keep that in mind.

> It has been occuring with multiple versions of Acrobat 6.0.x and 7.0.x 
(...)
> I don't see any other option than reporting this bug)

First place to check is with Adobe; first thing to do is to report/feedback/bug-report behaviors you find abnormal or wrong or incorrect to Adobe: it's their software which is implied/involved at the foremost perspective.

Comment 10

[Olivier Vit (just a reporter)]

It seems that it doesn't happen anymore since I updated a third party software, outside of SeaMonkey and Acrobat.
I don't understand why it could have interfered, but it also solved an issue between SeaMonkey and Real Player