Closed Bug 246560 Opened 20 years ago Closed 19 years ago

[gtk2] Adobe Acroread, xpdf and other full-page plugins(mozplugger + openoffice, etc) are not working

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Linux
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: andy, Assigned: roc)

References

Details

(Keywords: fixed1.8, helpwanted, regression)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040612 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040612 Firefox/0.8.0+

If I load a pdf into Firefox (either a local file or off the net) Firefox
behaves like it's loading it, the Adobe splash image shows, Firefox diplays the
title of the pdf in the title bar, but the window is all grey, nothing is
rendered. This bug is in the latest nightlies, the 0.9 release candidate works fine.

Reproducible: Always
Steps to Reproduce:
1.load a pdf
2.
3.
Actual Results:  
Grey screen

Expected Results:  
It should display the pdf like it used to, like it still does in the 0.9rc

I can download pdf's and view them locally so it's not the end of the world
Component: General → Plug-ins
Product: Firefox → Browser
Version: unspecified → Trunk
WFM 2004072607 w/ http://www.rsc.ca/english/RFreport.pdf
Acrobat 5.0.8
Assignee: firefox → nobody
QA Contact: firefox.general → core.plugins
That's interesting. Was that a trunk or a branch build you were using, and what
Linux distribution are you using?
Trunk using GTK1, Gentoo 1.4.16
Yes you're right. It works with gtk-1 builds. It never occured to me to try
that. I've just made a gtk-1 build and the acroread plugin works. So it's just a
problem with gtk-2. Thanks for your help.
Summary: Adobe Acroread plugin is not working anymore → Adobe Acroread plugin is not working in gtk-2 builds
Assignee: nobody → blizzard
Summary: Adobe Acroread plugin is not working in gtk-2 builds → Adobe Acroread plugin is not working in gtk2 builds
(In reply to comment #4)
> Yes you're right. It works with gtk-1 builds. It never occured to me to try
> that. I've just made a gtk-1 build and the acroread plugin works. So it's just a
> problem with gtk-2. Thanks for your help.

Plugin works OK with Mozilla 1.8a2 gtk2 build ID 2004060402, but gives blank
(grey) screen with later versions (and also reproduced with Aug 13 trunk of
Mozilla 1.8a3)
It's the same story with the xpdf/mozplugger combination. With a gtk1 build they
can display the .pdf in Firefox but with a gtk2 build I just get a grey screen.
So the bug is not to do in the Acroread plugin, the problem is .pdf's
Summary: Adobe Acroread plugin is not working in gtk2 builds → Adobe Acroread and xpdf plugins are not working in gtk2 builds
Confirming on all recent Linux CVS trunk builds of Mozilla.

Also, Severity -> Normal (instead of Minor), since pdf is a standard file 
format widely used for documents on the Net - it's a royal PITA saving those 
documents just to be able to open them.
Severity: minor → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
These bugs might be related or even dupes:

Bug #198954 , Bug #242321 , Bug #219987
According to Asa's blog
(http://weblogs.mozillazine.org/asa/archives/007280.html) the GTK2+XFT build
will be the default Linux build for 1.8a6. I assume this will also be the case
for future releases. So I'm asking for blocker status for 1.8b.
Flags: blocking1.8b?
Keywords: regression
Flags: blocking-aviary1.1?
Update to version 5.0.10 of the adobe plugin.  Should fix it.

*** This bug has been marked as a duplicate of 198954 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Its not fixed in Firefox (build 20050202). Also not fixed in Mozilla nightly
build 20050124. Both are the gtk2+xft builds and I've been using Acrobat Reader
5.0.10 for a while now. But just for a safe measure I reinstalled Acrobat Reader
and got the latest nightly of Firefox. No luck. Can anyone confirm that it works
for them? It could very well be my setup, but I doubt it.
Do the plugins show up in about:plugins?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(In reply to comment #12)
> Do the plugins show up in about:plugins?

Yes and it definitly doesn't work. That other bug is that the acrobat plugin
uses 100% CPU. That is not the issue here. pdf's simply don't show in the
browser. CPU use doesn't go above 1% for me
(In reply to comment #12)
> Do the plugins show up in about:plugins?

For me: Yes. In fact, is does even load, i.e. the Adobe Acrobat splash screen
with loading progress information appears. It's just that afterwards nothing is
displayed in Mozilla (blank content area). See also the initial comment of this bug.
It's working here for me.  Are you sure you don't have another copy of the adobe
reader installed somewhere else that is being picked up?
(In reply to comment #15)
> Are you sure you don't have another copy of the adobe
> reader installed somewhere else that is being picked up?

Yes. It says 5.0.10 in the splash screen window.
Could this be an issue with GCC ABI incompatibilities?
(In reply to comment #15)
> It's working here for me.  Are you sure you don't have another copy of the adobe
> reader installed somewhere else that is being picked up?

Is that a gtk2 build it's working in?
It is definitely not working with Mozilla 1.8b Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8b) Gecko/20050203

File name: nppdf.so
MIME Type 	Description 	Suffixes 	Enabled
application/pdf 	Portable Document Format 	pdf 	Yes

Acrobat Reader
x86 linux 5.0.10 Nov 8 2004 13:14:17

This is using gtk+xft build

Compiler  	Version  	Compiler flags
gcc 	gcc version 3.3.4 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align
-Wno-long-long -pedantic -pthread -pipe
c++ 	gcc version 3.3.4 	-fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe
-I/usr/X11R6/include

Configure arguments
--enable-application=suite --disable-tests
--enable-extensions=default,irc,tasks,negotiateauth --without-system-nspr
--without-system-jpeg --without-system-zlib --without-system-png
--without-system-mng --disable-debug '--enable-optimize=-O2 -gstabs+'
--enable-crypto --enable-default-toolkit=gtk2 --enable-xft --disable-freetype2
--disable-xprint

Acrobat splashscreen shows but the tab stays empty with a gray background. Note
that bug 198954 says something about a white background and 100% CPU usage which
is not the case here.

The same Acrobat plugin works perfectly on the gtk1 build: Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.8b) Gecko/20050203

Compiler  	Version  	Compiler flags
gcc 	gcc version 3.2.3 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align
-Wno-long-long -pedantic -pthread -pipe
c++ 	gcc version 3.2.3 	-fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe
-I/usr/X11R6/include

Configure arguments
--enable-application=suite --disable-tests
--enable-extensions=default,irc,tasks,negotiateauth --without-system-nspr
--without-system-jpeg --without-system-zlib --without-system-png
--without-system-mng --disable-debug '--enable-optimize=-O2 -gstabs+'
--enable-crypto

I suggest nominating this as blocking Mozilla 1.8
So has anybody figured out if this is a binary-compatibility issue or a GTK1 vs.
GTK2 issue?  If it's the former, it's probably something we could fix for 1.8,
if the latter, it seems likely to be unfixable without plugin changes.

In any case, it's too late for 1.8b.
Flags: blocking1.8b?
Flags: blocking1.8b2?
Flags: blocking1.8b-
I don't know what you mean by "binary compatibility issue". I compile xpdf and
Firefox from the code with the same tools. If I make a gtk1 build Firefox
renders .pdf's in the browser window. If I make a gtk2 build I have to use a
seperate instance of xpdf. Gtk1 builds can use xpdf as a plugin. Gtk2 builds can't
Does xpdf use gtk1.2?
(In reply to comment #22)
> Does xpdf use gtk1.2?

xpdf does not use GTK at all (neither version 1 or 2).
From bug 282928 : 

a spin-off of bug 242321

This was introduced by the patch for bug 242122. Backing out the patch solves
the problem, but not entirely. I can view PDF and other file types (I configured
to be rendered by mozplugger. eg. postscript by gv, oowrite and msword by
oowrite, etc) plugged inside mozilla, but mozilla's response to back button
becomes very erratic with a PDF file loaded. Perhaps, that's yet another bug.
*** Bug 282928 has been marked as a duplicate of this bug. ***
Summary: Adobe Acroread and xpdf plugins are not working in gtk2 builds → [gtk2] Adobe Acroread, xpdf and other full-page plugins(mozplugger + openoffice, etc) are not working
Thankyou very much. It is very good to be able to work with Firefox again. Very
many papers are only available as pdf's. This bug has been driving me nuts.
Sometimes I even had to use wget to fetch a pdf. Thanks again for the fix. 
Attachment #175928 - Attachment description: Patch t o back out the fix for bug 242122 → Patch to back out the fix for bug 242122
Although I agree that this bug is very annoying (I ended up disabling the
pluging for PDF), we can't simply back out the patch for bug 242122 because the
patch was landed to fix bug 242122 (btw, when refering to another bug, don't use
the URL but just write 'bug xyz' and bugzilla will do the rest for you). We need
to come up with a solution that fixes both bug 242122 and this bug.
Plussing.  We really ought to get this fixed soon.  I don't want to ship this
bug in final, and if we don't get it for b2, we will be cutting it close.

Who can help out here?
Flags: blocking1.8b2?
Flags: blocking1.8b2+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Blizzard and Caillon, no one's stepped up here and 1.8b2 needs to happen ASAP.
Should we pull this from the list, push it out to 1.8b3 or do you still want to
try to get it in to b2?
Flags: blocking1.8b3+
Flags: blocking1.8b2+
Flags: blocking1.8b-
*** Bug 292213 has been marked as a duplicate of this bug. ***
no progress and not a regression from 1.0. unblocking.
Flags: blocking1.8b3+ → blocking1.8b3-
Flags: blocking1.8b4?
This is a major regression from SeaMonkey (in case we're still tracking those in
Firefox-land), and makes Firefox on Linux that much more painful to use... 
There's no traction because the code in question is not very strongly owned, but
perhaps that means that drivers should contact what we do have in the way of
owners for it and ask them to help out here?
I have PDF type handled by "Open with acroread" -- works great.  What do I need
to set to reproduce this bug?

Giving to jst to presume on his good nature; he's a better owner than blizzard
for Core/Plug-ins bugs at any rate.

/be
Assignee: blizzard → jst
Status: REOPENED → NEW
brendan: you need to put the nppdf.so file that came with adobe reader into the
app plugins directory or ~/.mozilla/plugins/ (or just use a symlink).

And this is a regression from ff 1.0.  With the plugin from Adobe Reader 7.0-2,
I can load pdfs with ff 1.0.4, but not with current trunk.
http://www.adobe.com/products/acrobat/readstep2.html
Renominating in light of comment 35.

/be
Flags: blocking1.8b3- → blocking1.8b3?
Flags: blocking1.8b4?
Flags: blocking1.8b4+
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Whiteboard: [ETA ?]
Severity: normal → major
Keywords: helpwanted
*** Bug 266416 has been marked as a duplicate of this bug. ***
Are we sure Bug 266416 is a dupe of this one here? Bug 266416 was caused by a
compiler change (ABI change?) which broke at least the plugin for the Reporter
of that bug (quote: "mozilla-2004-08-05-12-trunk was compiled with gcc-3.2.3,
mozilla-2004-08-05-23-trunk was compiled with gcc-3.3.4, -12 works fine, -23
does not).
From the way it's described it looks like it's the same bug. I can't test if
using gcc-3.2.3 fixes the issue for me because I can't get gcc-3.2.3 to compile
with gcc-4.0.1. Perhaps the people involved in Bug #266416 could test the patch
attached to this bug and see if it fixes the problem for them?
I can reproduce this now. I doubt it's an ABI issue since my branch builds with
the same compiler don't have the bug.
Roc, any chance you could have a look at this? I won't be getting to this any
time soon.
Attached patch fixSplinter Review
This fixes it and does not appear to regress 242122.

Apparently we must set SubstructureRedirectMask or these plugins don't work. I
don't know why. It seems wrong because, as far as I can tell from the
documentation, the only effect it will have here is to stop Circulate,
Configure, and Map commands on the child_widget from taking effect. Maybe I'm
understanding it wrong.
Assignee: jst → roc
Status: NEW → ASSIGNED
Attachment #193628 - Flags: superreview?(blizzard)
Attachment #193628 - Flags: review?(blizzard)
Flags: blocking1.8b5+
Nice patch. Just one line. Fixes the problem (tested here with xpdf) and doesn't
regress the flash problem. Good job. Thanks.
Comment on attachment 193628 [details] [diff] [review]
fix

r+sr+a=brendan, rubber stamped one-line change
Attachment #193628 - Flags: superreview?(blizzard)
Attachment #193628 - Flags: superreview+
Attachment #193628 - Flags: review?(blizzard)
Attachment #193628 - Flags: review+
Attachment #193628 - Flags: approval1.8b4+
Whiteboard: [ETA ?]
Blizzard isn't confident in the patch, so I'm going to hold off landing *on
branch* until he can give me more feedback, or we can get more testing done with
the trunk builds.
Marking FIXED, although we may reopen if the fix is not palatable.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
*** Bug 302645 has been marked as a duplicate of this bug. ***
Has anyone identified any regressions in trunk builds due to roc's fix?  I have
not heard of anything.

/be
tracy, could you verify that this works on the trunk?  and then we can get it in
on the branch.  thanks.
(In reply to comment #51)
> tracy, could you verify that this works on the trunk?  and then we can get it in
> on the branch.  thanks.

It's easy money that there won't be any regressions in the stock Linux/GTK/Xt
versions most people use.  Anyone want to lay a bet?

The point of baking on the trunk was to get wider testing.  I think we have got
it, or else we *won't* get it unless we take this on the branch and ship it in
the beta.  So let's do that.

/be
checked in on branch.
Keywords: fixed1.8
Works fine in [Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050901
Firefox/1.0+]. No obvious problems with Adobe Reader 7.0.1, Flash 7.0.25.0,
RealPlayer 10.0.6, Java 1.5.0.04 and DjVuLibre 3.5.14. System configuration:
SuSE Linux 9.2, GTK+ 2.4.9.
For me this only works when I use a fresh profile. Using my regular profile
Flash still doesn't work.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050901 Firefox/1.0+
Dennis: on which builds does Flash work/not work for you? Did it work before
this patch, or not?
The last build where Flash works for me is: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8b4) Gecko/20050830 Firefox/1.0+
In all following builds it only works with a new profile.
Everything works fine here (Flash and now even acroread) with my existing, old
profile on a SeaMonkey build from 1.8 branch. I couldn't get acroread to work
here before, and now, with the patch, it works as it should.

From my viewpoint I can verify the fix (not setting yet due to comments made
before).
I cannot confirm any Flash problems. Everything is working fine, both Flash and
acroread, as well as realplay and DjVuLibre. Everything was tested with a
profile that is 6 months old - and with a new profile, it works as well.
realplay worked before the patch as well, but DjVuLibre didn't - now it does.

Last tested with [Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8b4) Gecko/20050902
Firefox/1.0+]
Hm, when I go to www.nin.com or www.angryalien.com I see a gray box appear for a
fraction of a second and when I put on my headphones I hear the sound beeing
initialized. It seems the flash bit gets started but doesn't display anything.
Found the culprit. After reading about Bug 306754 on the Mozilla Quality blog
and reading the comments I disabled the adblock extension and Flash started to
work again.
I updated adblock to the version mentioned in comment #17 in Bug 306754 and
everything works fine now.
Based on that, verifying.
Status: RESOLVED → VERIFIED
*** Bug 304007 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: