12.79 KB, image/png
17.92 KB, image/png
101.87 KB, image/x-pict
94.93 KB, image/x-pict
905 bytes, patch
Brian Nesse (gone): review+
Simon Fraser: superreview+
|Details | Diff | Splinter Review|
1.41 KB, message/rfc822
Any PDF file I open with trunk builds returns a blank page and no plug-in interface. If a click around the Acrobat toolbar buttons sometime appear or some parts of the interface, but the document pages still blank. Plug-in PDFViewer 5.0 MacOS 8.6. Mozilla 1.1a+ Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1a+) Gecko/20020703 1.0.0 branch builds don't display this bug.
The plug-ins triage team (av, beppe, peterl, serge and shrir) have reviewed this issue and have made the following determination: mac8.6 is an unsupported platform
BTW I have the same problem under 9.1. Can you reproduce this under 9.1?
hmm, we have not had any other reported cases of that on 9.1, or at least we are unaware of that. I am reopening this bug to ensure this gets tested under 9.1 by our QA. Bejamin: what version of Acrobat are you using? Shrir: can you please check this out under 9.1?
oh, also Bejamin were you using a mozilla nightly trunk build or a mozilla nightly branch build, or a Netscape branded branch build? And can you please tell us what the date is of the build?
he is using a nightly trunk (mozilla). this would be low priority for me right now, will check tho.
Today build. Mozilla 1.1a+ Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1a+) Gecko/2002071203 On my computer under 9.1 I use Acrobat 4.0... but I will try later with the last version of Acrobat Reader 5...
oh yeah..certainly use acrobat 5 ..the latest. We had issues with acrobat 4. let me know...
thanks Benjamin -- that will be very helpful
I'm confirming this bug. I totally see the problem as described in the first comment (good report!). I wonder when this regression popped up? Is it reproduceable in RC1 or 0.9.9?
Between 1.0 and 1.1a I think.
*** Bug 156126 has been marked as a duplicate of this bug. ***
I was the reporter for bug 156126 which has now been marked as a duplicate of 155708. The description of bug 155708 is exactly the same as what I am seeing [ in bug 156126] with the particular combination of Mac OS 9.2.2 US & Acrobat Plug-in 5.0.5 with numerous successive nightly builds of Mozilla 1.1 including today's Build ID 2002071808. The details given in bug 156126 include attachments of a screenshot and a stdlog file. This bug never occurs with numerous successive nightly builds of Mozilla 1.0.0 nor with the current 1.0.1 versions. This bug makes Mozilla 1.1 completely useless as a browser for readers of scientical & technical journals which are nowadays commonly published as full text online, as PDF files of each journal paper, in parallel to the printed versions.
*** Bug 106112 has been marked as a duplicate of this bug. ***
Mac G3, OS 9.2.2. Using trunk build 2002071808 and Classic theme, I was able to read PDF files. But I then downloaded, installed and selected the 'Little Mozilla' theme, decided I did not like it and went back to the 'Classic' theme (each time, of course, shutting down and restarting Mozilla). I then found that I could no longer read the PDF files. After I had closed down and restarted my computer, I could once again read the PDF files.
Computer: Mac G3. OS 9.2.2. Mozilla Build: 2002072308 (trunk). I can view PDF files in Mozilla, but I cannot download and save anything that will subsequently display the PDF file. In Netscape 4.79, saving as 'Source' produces a file that Acrobat Reader 5.0 opens and displays complete. In Mozilla, saving page as 'Complete' produces a Mozilla file and a folder full of other files; saving as 'HTML only' produces only the Mozilla file. But opening in Acrobat Reader will show either a blank page or just the first screen of the PDF file.
Mac G3 - OS 9.2.2 (intern. Eng.) - Mozilla 2002072308 And yet one more comment. I tried saving the PDF file as xxx.pdf instead of xxx.html. That resulted in a file with the Acrobat icon, but it still couldn't be opened.
Mac G3 (old beige) - OS 9.2.2 (Intern. Eng.) - Mozilla 2002072308 (trunk). I have now gathered more information. 1. VIEWING PDF FILES: When opening a pdf file (e.g. on <http://pdf.thelancet.com/pdfdownload?uid=llan.360.9327.news.21756.1&x=x.pdf>), it appears with its upper portion whited-out. If the screen display is scrolled right down and then up again, the pdf file appears complete. 2. INABILITY TO SAVE PDF FILES: This turns out to be site-specific. The behaviour I described in my earlier addition to this bug report occurred on <https://secure1.onetel.net.uk/cgi-bin/uk/onesys.wsc/net/net-billview.w?id=1000254382&id2=jjlQjxbFbghlafaa>, which is a password-protected 'View bills online' site. On other sites, e.g. the one given under 1. above, the pdf file can be saved satisfactorily.
Created attachment 92952 [details] Screenshot of PDF displayed on Moz1.1b but lacking Acrobat controls notice that the ususal Acrobat iconic controls [e.g. floppy symbol, printer symbol etc] do NOT appear immediately above the top left corner of the PDF display sub-window, as they should do. Above this can be seen the PPP connect symbol and that the current theme is Little Mozilla 1.1.
Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/20020725. Build ID 20020725o8. Mac OS 9.2.2 US English. I confirm the additional comment # 17 and #18 from Michael Graubart. The scroll down and then up again 'work around' works AOK everytime. This seems to imply that this drawing bug might have a trivial remedy---especially as it does not affect either Mozilla 1.0.0 nor 1.0.1. I have repeated this separately with both the 'Modern' and 'Little Mozilla 1.1' themes enabled. In addition, I was able to print the displayed PDF file <http://bmj.com/cgi/reprint/325/7357/176> but only if I used the Print... option of the File menu. If I tried the Command + P shortcut nothing happened. If I tried to Preview the printing only the 1st Mozilla preview progress bar appeared but no preview window was actually drawn. In addition, I was able save a valid pdf file from the The Lancet site---only by using the Save Page As... option off the File menu. After the failed attempt to print or save the generated pdf file on the OneTel site my system was left in an unstable state & Acrobat Reader froze.
The plot thickens ... Try this URL <http://www.iom.edu/iom/iomhome.nsf/WFiles/TransFattyAcids/$file/TransFattyAcids.pdf> after you applied Graubart's "scroll down all the way & then scroll back up all the way" work around, after the document is "Done". In this case, the Acrobat Reader is drawn completely normally, after doing the work around, so maybe the HTML code has something to do with the bug as this was a direct link to the PDF file rather than to a page from which it can be downloaded by then selecting a link. Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/20020725. Build ID 20020725o8. Mac OS 9.2.2 US English.
Created attachment 93025 [details] Screenshot of Acrobat Reader window drawn AOK on Moz 1.1b This is the illustration that goes with additional comment # 21. Note that everything is drawn absolutely normally---once the work around that been applied.
Mac G3 (old beige) - OS 9.2.2 (International English) - Classic theme. When I clicked on the link in A. Wight's message, Acrobat Reader opened but the screen was blank and had no scroll bar so that I could not apply the 'Graubart workaround'. By clicking on Acrobat reader in the Application menu, I could bring up the Acrobat tool-bar, but still no text on screen. When I quitted from Acrobat and copied and pasted the URL into the Navigator location bar and opened, Acrobat again started, but this time a bit of an image and the scroll bar appeared, so that I was able to apply the 'Graubart workaround'. Then the full document became completely readable. So this site did not really work any differently from the others that have been tried in this context. It is not clear to me what has been found to be different on this site.
Created attachment 93072 [details] Screenshot of PDF site after activating link in e-mail Confirming that the PDF problems still exist in Build 2002072703 (trunk), this is how the window looks after activating the link to the PDF site in an e-mail.
Created attachment 93073 [details] Scrteen appearance after activating link in e-mail and then scrolling down and up This is what the screen looks like after activating the link to the site in an e-mail, then scrolling down and up and scrolling down a little way again to show the title of the PDF document.
Mac G3 (old beige). OS 9.2.2 (Intern. Engl.) Classic theme. Mozilla Build: 2002072703 (trunk). I confirm that the various PDF problems still exist in this new build. But in addition, there is another aspect of the problems. In general, if one receives an e-mail that contains a link to a web-site and clicks on it, the site opens in a new window. But if it is a direct link to a PDF document, the latter (after applying the scrolling-down-and-up workaround) appears as part of the original mail window. In the case of two earlier documents mentioned in this series of reports and comments, namely <http://bmj.com/cgi/reprint/325/7354/3.pdf> and <http://pdf.thelancet.com/pdfdownload?uid=llan.360.9327.news.21756.1&x=x.pdf>, the mail window appears as fragmentary remains. But in the new document mentioned by A. Wight, namely <http://www.iom.edu/iom/iomhome.nsf/WFiles/TransFattyAcids/$file/TransFattyAcids.pdf>, a large part of the mail window remains at the top of the screen, leaving little room for the PDF document even after the workaround has been applied. The two new attachments (screenshots) demonstrate this. If, instead of clicking on the link in the original e-mail, the URL is copuied and pasted into the Navigator location bar, this problem does not arise.
Thanks everyone for helping to reproduce this bug but I think we've got enough info on how to repro this bug. What would really help is to narrow down WHEN this happened. Netscape's internal sweetlou server just so happens to keep Mozilla Mac Classic daily trunk builds back at least through June so I was able to determine this regression seemed to first occur between 2002061108 and 2002061203. Here's the bonsai query: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=06%2F11%2F2002+8%3A00&maxdate=06%2F12%2F2002+3%3A00&cvsroot=%2Fcvsroot Many checkins :( I've already tried with no luck backing out many of those changes including the suspicious ones to the view module. In the debugger, I'm seeing the inital mWindow->Invalidate(0) being called and also updateEvents seem to being sent so I still have no idea why PDFs don't get initial drawn. cc:ing some more Mac heads if they've maybe seen other similar regressions.
Created attachment 93124 [details] [diff] [review] patch v.1 ...and 5 minutes later I find the problem. Looks like the repeating full-page plugin timer was a casualty of a forest fire. No worries, this 1-line patch seems to do the trick. reviews?
Comment on attachment 93124 [details] [diff] [review] patch v.1 One of these days we really need to eliminate the distinction between fullpage and embeded... r=bnesse.
Comment on attachment 93124 [details] [diff] [review] patch v.1 sr=sfraser
Comment on attachment 93124 [details] [diff] [review] patch v.1 a=asa (on behalf of drivers) for checkin to 1.1
patch in trunk, marking FIXED
works great: Mozilla 1.1b Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/2002073003 Mac8.6 Thanks!
Mac OS 9.2.2 English-North American Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/20020730 Build ID 2002073003. theme = Little Mozilla 1.1 I have just tested this fix, on <http://www.cmaj.ca/cgi/reprint/166/13/1649.pdf>, & it works fine. Very many thanks !!!!
Build 2002073103 solves some but not all PDF problems. On the first URL quoted by A. Wight, namely <http://bmj.com/cgi/reprint/325/7354/3.pdf> the PDF file now appears absolutely correctly. On the most recent one he gave, namely <http://www.iom.edu/iom/iomhome.nsf/WFiles/TransFattyAcids/$file/TransFattyAcids.pdf> the PDF file is there in full, but still part of the original e-mail message that contained the link, so that it appears only in the lower part of the window, which means scrolling (not to make it appear, but to be able to read it). I then tried forwarding the e-mail containing the link to myself so that I could download it again, but in Netscape 4.79, where it opened (as it should) in a new Navigator window. Finally, on <https://secure1.onetel.net.uk/cgi-bin/uk/onesys.wsc/net/net-billview.w?id=1000254382&id2=jjlQjxbFbghlafaa> (once one enters my login name and password) the PDF bills can be viewed perfectly well, but still cannot be saved to disk. I had also wondered whether this partial fix of the drawing problem might have solved my Hotmail bug (Bug 157565), but it has not.