User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a Mnenhy/0.7.2.0 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a Mnenhy/0.7.2.0 I have Adobe Acrobat 5.0.5 installed on my Win 98SE OS, and within that program's preferences, I've chosen the option "Display PDF in browser." This (correctly) copies the Acrobat plug-in (nppdf32.dll, ver. 5.00) to the SeaMonkey plugins subdirectory. Using SeaMonkey build 20050812 (before the skinVersion change), the browser recognized the plug-in and displayed all PDF documents within a browser window or tab. With SeaMonkey 1.0a (installed clean to a new profile), the Acrobat plug-in is included on the about:plugins list, and is marked as enabled. However, when clicking on any link associated with a PDF document, SeaMonkey 1.0a brings up a handling dialog box ("What do you want SeaMonkey to do with this file?") instead of making use of said plug-in. Reproducible: Always Steps to Reproduce: 1. Start SeaMonkey 1.0a browser on Win 98 system with Adobe Acrobat 5.0.5; latter program should have preferences option "Display PDF in browser" checked 2. Click on link to any PDF document 3. Example: http://www.missouri.edu/~tigers/Smith_et_al.pdf Actual Results: SeaMonkey 1.0a brings up an Opening dialog box, asking how it should handle PDF files (options include: open with default app (Adobe Acrobat), open with..., and save to disk). Expected Results: The browser should have made use of the Acrobat plug-in and displayed the PDF document within the browser window or tab. It has been suggested that installation of the current free Acrobat Reader (ver. 6.0.4) may resolve this difficulty through updating the plug-in file nppdf32.dll. However, this may also cause a conflict between the full Acrobat software and the free Reader with future PDF document handling. Since I rely on the Acrobat software for frequent document conversion, I don't wish to chance this. The Reader also cannot be uninstalled independent of the full software. Additionally, the version 5.00 plug-in worked for the 20050812 build, leading me to believe a change in SeaMonkey 1.0a is at the heart of this behavior. It should be noted that version 5.0.5 of the Acrobat software is the only version compatible with Win 98--Adobe will not be releasing any updates to its Acrobat software for the Win 98 OS.
Confirming. I have the free Acrobat Reader 5.0.5 installed on my Windows 95 PC. I also have the option to display PDF files in the browser enabled, and have the plug-in installed. I'm seeing the same behavior. Additionally, 50% of the time I click on a link opening a PDF file, the file handling dialog box shows up and immediately places itself in the background, behind the SeaMonkey window, unfocused.
Please check the value of the pref plugin.scan.Acrobat, use about:config to check it.
(In reply to comment #3) > Please check the value of the pref plugin.scan.Acrobat, use about:config to > check it. My settings are as follows: default string 5.0 Unfortunately, since I no longer have build 20050812 on my computer, I can't make a cross-comparison.
-- Update -- Due to my PC's SCSI HD suffering a spindle/motor failure, I had to resort to my laptop for computer work, also using Win 98SE. SeaMonkey 1.0a wasn't installed, and neither was Adobe Acrobat. Installed the former to a new profile, and installed Acrobat Reader 6.0.4 (after updates). The latter's plug-in--nppdf32.dll--has a version number of 220.127.116.113051500. SeaMonkey doesn't recognize this version of the plug-in either, even with the config option plugin.scan.Acrobat set to "6.0." I've also tried setting it to the plug-in's specific version number, 18.104.22.1683051500, without any success. It appears that plugin.scan.Acrobat isn't functioning properly for any Acrobat plug-in version on Win 95/98 systems. I wonder what the difference is with the Win 2000/XP plug-in(s) that this bug isn't seen with that OS...
*** Bug 316129 has been marked as a duplicate of this bug. ***
hmm, mozilla believes that a screen reader is active.
Created attachment 202848 [details] [diff] [review] patch this function returns a BOOL, not a HRESULT. Unfortunately I can't test this patch with a screenreader active; aaronlev, could you do that?
The reason this is an issue is that on WinXP, this function returns TRUE (1), and a zero value for the screen reader presence; while on win98, it returns FALSE for me, leaving the value as-is, which means it's a pretty random value, which gets interpreted as true, of course.
(and SUCCEEDED is true for any positive value)
that is, non-negative value
fixed on trunk: Checking in widget/src/windows/nsLookAndFeel.cpp; /cvsroot/mozilla/widget/src/windows/nsLookAndFeel.cpp,v <-- nsLookAndFeel.cpp new revision: 1.53; previous revision: 1.52 done
Comment on attachment 202848 [details] [diff] [review] patch this is a low-risk patch that fixes the PDF plugin (and maybe others), by handling errors from SystemParameterInfo correctly. (mostly a win9x issue)
Can we bake for longer on the trunk and then we'll consider for the branch.
Comment on attachment 202848 [details] [diff] [review] patch Not taking for 22.214.171.124
ah well. fixed on MOZILLA_1_8_BRANCH: Checking in widget/src/windows/nsLookAndFeel.cpp; /cvsroot/mozilla/widget/src/windows/nsLookAndFeel.cpp,v <-- nsLookAndFeel.cpp new revision: 126.96.36.199; previous revision: 188.8.131.52 done
11 years ago
*** Bug 339166 has been marked as a duplicate of this bug. ***
*** Bug 340927 has been marked as a duplicate of this bug. ***
Comment on attachment 202848 [details] [diff] [review] patch approved for 1.8.0 branch, a=dveditz for drivers
MOZILLA_1_8_0_BRANCH: Checking in widget/src/windows/nsLookAndFeel.cpp; /cvsroot/mozilla/widget/src/windows/nsLookAndFeel.cpp,v <-- nsLookAndFeel.cpp new revision: 184.108.40.206.2.1; previous revision: 220.127.116.11 done