Bug 10510 – REGRESSION: Adobe PDF Plugin 7 doesn't work

• Status: RESOLVED
• Resolution: INVALID
• Component: Plug-ins

[Kevin M. Dean]

Using the Adobe PDF Plugin to view pdfs doesn't appear to work on any site. The file downloads, but no plugin interface appears with the pdf content.

[Alexey Proskuryakov]

Could you please give an example of a site where you see this problem?

[Kevin M. Dean]

Any site with PDF files will do, but here's some from Adobe:

<http://partners.adobe.com/public/developer/pdf/index_reference.html>

Just click on one of the smaller pdfs for a quick demo.

I'm also getting the following message in the console when trying to load a pdf there.

2006-08-22 16:27:09.257 WebKit[2615] CFLog (21): Error loading /System/Library/Frameworks/WebKit.framework/WebKit:  error code 4, error number 0 (Symbol not found: _WebCoreUnicodeDirectionFunction
  Referenced from: /System/Library/Frameworks/WebKit.framework/WebKit
  Expected in: /Applications/WebKit.app/Contents/Resources/WebCore.framework/Versions/A/WebCore
)

[Alexey Proskuryakov]

I could reproduce with the latest AdobePDFViewer.plugin (version 7.0.5, as installed with Reader 7.0.8) and a local TOT build.

It seems that the plugin loads a system copy of WebKit framework dynamically, and that is of course incompatible with TOT WebCore and WebKit. So, on one hand it's not something we can fix, Adobe needs to address this problem. On the other hand, this is only an issue for nightlies and local TOT builds - as soon as new WebKit ships with the OS, everything should be back to normal.

Since this is a pretty important issue, I'm confirming and leaving this open for someone to double-check my findings, but I think that this is INVALID.

[Rudi Sherry]

The Adobe plug-in does not explicitly load WebKit; it links with the WebKit so that it will use the system's.  Here is a guess: WebView.m, in -[initWithFrame:frameName:groupName:], unsets DYLD_FRAMEWORK_PATH in order to fix bug 4286 where .Mac preferences wasn't loading properly.  I think this is causing AdobePDFViewer to somehow load the system WebKit because TOT is no longer in the DYLD_FRAMEWORK_PATH.  I would need someone more familiar with mach-o loading to confirm this.

[Alexey Proskuryakov]

(In reply to comment #4)
> The Adobe plug-in does not explicitly load WebKit; it links with the WebKit so
> that it will use the system's.

  Interesting - looks like otool might have fooled me:

$ otool -L /Users/ap/Desktop/AdobePDFViewer.plugin/Contents/MacOS/AdobePDFViewer 
/Users/ap/Desktop/AdobePDFViewer.plugin/Contents/MacOS/AdobePDFViewer:
        /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.0.0)
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 494.0.0)
        /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 725.0.0)

>  Here is a guess: WebView.m, in
> -[initWithFrame:frameName:groupName:], unsets DYLD_FRAMEWORK_PATH in order to
> fix bug 4286 where .Mac preferences wasn't loading properly.

  Sounds feasible!

[Rudi Sherry]

Sorry, my bad -- the AdobePDF plugin does not link with WebKit. The plugin is loading Acrobat, and Acrobat dynamically loads WebKit with a hard-coded path "/System/Library/Frameworks/WebKit.framework".  Acrobat loads it dynamically -- rather than linking with it -- because it supports 10.2 which doesn't have WebKit.

I don't see any way we will fix this for Acrobat 7; I believe Acrobat 8 should work correctly (I can't say more than that).

I'm also not sure why it fails to work, though. I would assume that this is a problem with multiple (incompatible?) WebKit frameworks loaded at the same time, but I'm not enough of an expert on the Objective-C runtime to know for sure.

[Alexey Proskuryakov]

Acrobat 8 works with TOT WebKit fine, closing.

[Alexey Proskuryakov]

*** Bug 14644 has been marked as a duplicate of this bug. ***