Plugin overruled by a disabled plugin for the same MIME type(?)
Simon Bünzli
Our NPAPI plugin for displaying PDF documents seems to be ignored by
Firefox 3.6 if Adobe's nppdf32.dll is found in Firefox's plugins
subdirectory - even if Adobe's plugin has been disabled. Unless
nppdf32.dll is removed, our plugin's DLL seems to never even be loaded
and Firefox just continues displaying the previous page when a link to a
PDF document is clicked (while the address bar is correctly updated).
Going through both the NPAPI documentation and Firefox's source code, I
haven't been able to figure out why that happens to our plugin while
e.g. Foxit's doesn't seem to suffer from the same issue.
Before I start setting up the whole build environment for Firefox, I'd
like to know if this is a known issue or whether some of you just have
an idea why this issue might be happening.
In case you want to reproduce the issue,
1. install Adobe Reader 9 or X, if you haven't got it already;
2. install the SumatraPDF pre-release build including the browser plugin
(Show Options!) from
http://blog.kowalczyk.info/software/sumatrapdf/prerelease.html ;
3. disable Adobe's and all other PDF plugins and
4. try to load a PDF document.
The source file for our plugin is available at
http://code.google.com/p/sumatrapdf/source/browse/#svn%2Ftrunk%2Fsrc%2Fbrowserplugin
Any help would be much appreciated!
Cheers,
Simon
Alessandro Pignotti
you're are probably hitting this bug
https://bugzilla.mozilla.org/show_bug.cgi?id=581848
The issue should be solved in Firefox 4 betas
Regards,
Alessandro
> _______________________________________________
> dev-tech-plugins mailing list
> dev-tech...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-plugins
Simon Bünzli
Alessandro Pignotti schrieb am 23.02.11 17:05:
> you're are probably hitting this bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=581848
Thanks for the pointer.
How could I verify that this is indeed that bug? IOW: Is there any way
that we could get in before Adobe's plugin if it were that bug?
So far I've tried renaming all exposed strings to be alphabetically
before "Adobe" and renaming the plugin itself so that it sorts before
nppdf32, but both to no avail. And manually reordering pluginreg.dat
doesn't seem to help, either. In fact, the offending nppdf32.dll isn't
even listed in there...
Cheers,
Simon
Simon Bünzli
> How could I verify that this is indeed that bug? IOW: Is there any way
> that we could get in before Adobe's plugin if it were that bug?
To answer my own question:
MOZ_PLUGIN_PATH seems to be the first place where Firefox looks for
plugins, so setting it to the directory of our plugin makes it take
precedence. Foxit's PDF plugin uses this and we'll make use of this fact
as well if there are no better alternatives.
Cheers,
Simon