Closed Bug 236195 Opened 20 years ago Closed 8 years ago

Unable to use Acrobat Reader as helper application

Categories

(Plugins Graveyard :: PDF (Adobe), defect)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: L.Wood, Assigned: peterlubczynski-bugs)

References

Details

I am unable to view all pdfs in Acrobat Reader as a helper application.

I view a lot of large pdfs; watching mozilla's acrobat plugin strain to handle a
100Mb+ pdf file is not pleasant, particularly if you have to use Acrobat
simplified Chinese 6.01 (the only way to read academic papers written in China,
even when they don't contain Chinese fonts). I'd rather have Acrobat die on me
that mozilla-with-acrobat, and by using Acrobat separately I get better screen
management too.

I have attempted to tell mozilla not to use the acrobat plugin. But I can't.
When setting mozilla 1.6 to use Acrobat Reader as an external helper
application, I am told:

"Mozilla can handle this type internally. For such types, a Helper Application
will only be invoked if the server requests external handling."

...which is patronising and contrary to the user's wishes. I don't *want*
mozilla to handle it, thankyou. I want control over my own viewing experience.

I've also unchecked all the Web Browser Options in Adobe Acrobat's Internet
preferences. (I'm using 6.01 simplified chinese). No change there; plugin still
launches.

Despite deleting nppdf32.dll from the mozilla plugins directory, mozilla still
launches acrobat documents in the browser window using the plugin.

Eventually I realise that mozilla is invoking Acrobat, and that Acrobat is
somehow getting mozilla to load in nppdf32.dll from Acrobat's own Reader\Browser
directory. So I move that dll. Result: blank browser screen where pdf plugin
fails to load. No separate helper app launched.

Also, despite trashing/moving nppdf32.dll and quitting mozilla and Acrobat
Reader, about:plugins still claims the acrobat plugin is installed.
(about:plugins reporting is likely a different problem; another symptom is that
upgrading mozilla always requires Real to be reinstalled to get the realvideo
plugin working, even though the upgraded Mozilla's about:plugins claims Real
remains installed post upgrade. about:plugins' reporting is unreliable.)

I'm unclear here if this is Mozilla or Acrobat's fault. I suspect both are
involved; both have made the simple invoke-an-application-to-handle-this-file
process way, way way too complicated.

This is a regression on Netscape 4, which was able to launch acrobat pdfs using
a separate instance of a pdf-displaying application. I'm stuck with saving files
individually and opening them in Acrobat by hand.
I'm starting to regret adding that dialog. it is used to inform people that the
helper application they set for such content won't be used, so that it doesn't
look like a bug to them.

this is a known rfe; duping to the bug that will make this possible. note that
it's not quite trivial to make this possible w/o slowing down normal page loading.

note that mozilla will look for the acrobat plugin also in the acrobat
installation directory, not only in mozilla's plugin directory.

> So I move that dll. Result: blank browser screen where pdf plugin
> fails to load. No separate helper app launched.

not sure why that happens, have you restarted mozilla after that? it should
work... maybe mozilla finds some other pdf plugin somewhere.

*** This bug has been marked as a duplicate of 58554 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
I'm glad this dialog was added.  At least users are now aware that their
attempts at using an external application are futile.  Any way you look at it,
this is a current shortcoming of Mozilla's abilities.  Users who want to do
things like this are going to find out one way or another.  I think its better
that they're told up-front that what they want to do is impossible, rather than
having them blow a lot of time trying a dozen things and scouring the web for
answers.
I was able to get mozilla 1.6 to launch Acrobat Reader 6.0.1 as a separate
standalone helper app by deleting:

pluginreg.dat
registry.dat

from Documents and Settings\USER\Application Data\Mozilla\Profiles

so that about:plugins now *knew* mozilla didn't have the mozilla plugin, and
didn't attempt to launch the non-existent nppdf32.dll that I'd been removing.

Removing all instances of nppdf32.dll was not sufficient. about:plugins does not
stay up to date.

Having to delete the autogenerated plugins registry information by hand because
mozilla is unable to keep its about:plugins list up to date is unsatisfactory,
and not user-friendly.
(In reply to comment #3)
> Having to delete the autogenerated plugins registry information by hand because
> mozilla is unable to keep its about:plugins list up to date is unsatisfactory,
> and not user-friendly.

I agree. However, it is not supposed to be necessary, and isn't for me. file a
new bug.
I've now opened bug 236201 on the statefulness and suckiness of about:plugins
and its registry.
*** Bug 236441 has been marked as a duplicate of this bug. ***
Installed Acrobat 7.0. Result: browsed PDFs launched in sucky browser plugin,
rather than in preferred Acrobat Reader as helper app. Acrobat 7.0 is a vast
improvement on 6.0 (faster loading with plugins on demand, less annoying splash
screen, better internal searching) but its browser plugin is pretty much the
same and as sucky as ever, so no-one in their right mind would use it,
particularly since 7.0 launch speed is pretty damn spiffy, so using plugin
because it saves time waiting for Reader to read in own plugins is now non-argument.

Turning off 'Internet/Display PDF in browser' checkbox option in Acrobat 7.0
made absolutely no difference in behaviour here. PDFs still opened in sucky
browser plugin. Firefox's prefs dialog 'open in AcroExch' is of no help here,
since Acrobat itself seems to launch browser plugin via some callback or other.

Had to again find and trash all instances of nppdf32.dll on hard disk that
Firefox 1.0.3 and mozilla 1.7.3 wouldn't launch acrobat browser plugin. (Didn't
have the registry.dat runaround this time.)

This behaviour hasn't been resolved at all, much less is it a dupe of bug 58554.
Acrobat plugin behaviour and control over same needs fixing. So, regretfully
reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
? why is not a duplicate? That bug is about what you want - using external
applications even if a plugin is installed. nobody claimed it was resolved.
I believe that 318081 describes the same problem, and could be closed in favor of this one.

I hope this gets fixed.  I'd rather use xpdf to look at PDF files than Acrobat.
DUP of Bug 147309, isn't it? See Bug 194986 also.
Installed Acrobat Reader 9 with Firefox 2.

Acrobat Reader 9 has this _insane_ method of opening pdfs as separate browser windows that look like Reader windows, but show up in the browser taskbar list (with Reader icons and plugin- at the start of the title) and aren't fully functional - select File/Open in one of these windows, get "This action cannot be performed from within an external window [OK]".

This is actually worse than the alternative of viewing the pdf direct in the browser tab if I turn 'Display PDF in browser' back on in Reader.

How do I disable both browser view and this pseudo-independent external window view in Reader 9 so that I can just pass the files via mimetype to Reader? Or should I just downgrade to buggy, slow, crashing Reader 8?

http://blog.micropledge.com/2008/07/adobe-reader-9/
and how to remove the AIR thing I don't want to ever install?

Also, Acrobat Reader 9 is bloated. Add or Remove programs says 204MB. 204MB and Open/File doesn't work!
QA Contact: plugins
Component: Plug-ins → PDF (Adobe)
Product: Core → Plugins
QA Contact: plugins → adobe-reader
Version: Trunk → unspecified
Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.
Status: REOPENED → RESOLVED
Closed: 20 years ago8 years ago
Resolution: --- → INCOMPLETE
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.