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)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: andy, Assigned: roc)
References
Details
(Keywords: fixed1.8, helpwanted, regression)
Attachments
(2 files)
1.34 KB,
patch
|
Details | Diff | Splinter Review | |
1.31 KB,
patch
|
cbeard
:
review+
cbeard
:
superreview+
cbeard
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•20 years ago
|
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
Reporter | ||
Comment 2•20 years ago
|
||
That's interesting. Was that a trunk or a branch build you were using, and what Linux distribution are you using?
Reporter | ||
Comment 4•20 years ago
|
||
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)
Reporter | ||
Comment 6•20 years ago
|
||
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
Comment 7•20 years ago
|
||
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
Comment 8•20 years ago
|
||
These bugs might be related or even dupes: Bug #198954 , Bug #242321 , Bug #219987
Comment 9•20 years ago
|
||
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
Reporter | ||
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Comment 10•19 years ago
|
||
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
Comment 11•19 years ago
|
||
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.
Comment 12•19 years ago
|
||
Do the plugins show up in about:plugins?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter | ||
Comment 13•19 years ago
|
||
(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
Comment 14•19 years ago
|
||
(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.
Comment 15•19 years ago
|
||
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?
Comment 16•19 years ago
|
||
(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.
Comment 17•19 years ago
|
||
Could this be an issue with GCC ABI incompatibilities?
Reporter | ||
Comment 18•19 years ago
|
||
(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?
Comment 19•19 years ago
|
||
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-
Reporter | ||
Comment 21•19 years ago
|
||
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
Comment 22•19 years ago
|
||
Does xpdf use gtk1.2?
Comment 23•19 years ago
|
||
(In reply to comment #22) > Does xpdf use gtk1.2? xpdf does not use GTK at all (neither version 1 or 2).
Comment 24•19 years ago
|
||
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.
Comment 25•19 years ago
|
||
*** Bug 282928 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
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
Reporter | ||
Comment 26•19 years ago
|
||
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.
Reporter | ||
Comment 27•19 years ago
|
||
Patch to back out the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=242122
Reporter | ||
Updated•19 years ago
|
Attachment #175928 -
Attachment description: Patch t o back out the fix for bug 242122 → Patch to back out the fix for bug 242122
Comment 28•19 years ago
|
||
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.
Comment 29•19 years ago
|
||
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+
Comment 30•19 years ago
|
||
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?
Updated•19 years ago
|
Flags: blocking1.8b3+
Flags: blocking1.8b2+
Flags: blocking1.8b-
Comment 31•19 years ago
|
||
*** Bug 292213 has been marked as a duplicate of this bug. ***
Comment 32•19 years ago
|
||
no progress and not a regression from 1.0. unblocking.
Flags: blocking1.8b3+ → blocking1.8b3-
Updated•19 years ago
|
Flags: blocking1.8b4?
Comment 33•19 years ago
|
||
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?
Comment 34•19 years ago
|
||
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
Comment 35•19 years ago
|
||
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
Comment 36•19 years ago
|
||
Renominating in light of comment 35. /be
Flags: blocking1.8b3- → blocking1.8b3?
Updated•19 years ago
|
Flags: blocking1.8b4?
Flags: blocking1.8b4+
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Updated•19 years ago
|
Whiteboard: [ETA ?]
Updated•19 years ago
|
Severity: normal → major
Updated•19 years ago
|
Keywords: helpwanted
Comment 37•19 years ago
|
||
*** Bug 266416 has been marked as a duplicate of this bug. ***
Comment 38•19 years ago
|
||
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).
Reporter | ||
Comment 39•19 years ago
|
||
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?
Assignee | ||
Comment 40•19 years ago
|
||
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.
Comment 41•19 years ago
|
||
Roc, any chance you could have a look at this? I won't be getting to this any time soon.
Assignee | ||
Comment 42•19 years ago
|
||
I'm working on it.
Assignee | ||
Comment 43•19 years ago
|
||
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)
Updated•19 years ago
|
Flags: blocking1.8b5+
Reporter | ||
Comment 44•19 years ago
|
||
Nice patch. Just one line. Fixes the problem (tested here with xpdf) and doesn't regress the flash problem. Good job. Thanks.
Comment 45•19 years ago
|
||
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+
Updated•19 years ago
|
Whiteboard: [ETA ?]
Assignee | ||
Comment 46•19 years ago
|
||
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.
Assignee | ||
Comment 47•19 years ago
|
||
landed on trunk.
Assignee | ||
Comment 48•19 years ago
|
||
Marking FIXED, although we may reopen if the fix is not palatable.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Comment 49•19 years ago
|
||
*** Bug 302645 has been marked as a duplicate of this bug. ***
Comment 50•19 years ago
|
||
Has anyone identified any regressions in trunk builds due to roc's fix? I have not heard of anything. /be
Comment 51•19 years ago
|
||
tracy, could you verify that this works on the trunk? and then we can get it in on the branch. thanks.
Comment 52•19 years ago
|
||
(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
Comment 54•19 years ago
|
||
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.
Comment 55•19 years ago
|
||
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+
Assignee | ||
Comment 56•19 years ago
|
||
Dennis: on which builds does Flash work/not work for you? Did it work before this patch, or not?
Comment 57•19 years ago
|
||
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.
Comment 58•19 years ago
|
||
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).
Comment 59•19 years ago
|
||
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+]
Comment 60•19 years ago
|
||
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.
Comment 61•19 years ago
|
||
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.
Comment 63•19 years ago
|
||
*** Bug 304007 has been marked as a duplicate of this bug. ***
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•