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
WFM 2004072607 w/ http://www.rsc.ca/english/RFreport.pdf Acrobat 5.0.8
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.
(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
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.
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.
Update to version 5.0.10 of the adobe plugin. Should fix it. *** This bug has been marked as a duplicate of 198954 ***
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?
(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.
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. ***
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.
Created attachment 175928 [details] [diff] [review] Patch to back out the fix for bug 242122 Patch to back out the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=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?
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?
*** Bug 292213 has been marked as a duplicate of this bug. ***
no progress and not a regression from 1.0. unblocking.
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
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
*** 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.
I'm working on it.
Created attachment 193628 [details] [diff] [review] fix 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.
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
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.
landed on trunk.
Marking FIXED, although we may reopen if the fix is not palatable.
*** 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.
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 188.8.131.52, 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.
*** Bug 304007 has been marked as a duplicate of this bug. ***