Closed Bug 780284 Opened 12 years ago Closed 8 years ago

[10.8] QuickTime plugin seen by Firefox as "invalid" until some browser (e.g. Safari) loads it at least once from a foreground process

Categories

(Core Graveyard :: Plug-ins, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: smichaud, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: rdar://12030142)

Here's a strange little Apple bug in OS X 10.8 (Mountain Lion).  I don't know if the bug is in QuickTime or elsewhere.  If it's in QuickTime, Safari has learned how to work around it.  Or perhaps QuickTime somehow special-cases Safari.

The first time Safari is run, it creates (or triggers the creation of) a file in ~/Library/Preferences called com.apple.quicktime.plugin.preferences.plist.  Until that file has been created, Firefox (all versions) is unable to load any QuickTime plugins.  An attempt to do so will result in Firefox displaying the missing plugin icon.

Here's a testcase URL that can be used to demonstrate the problem:
http://www.bigfloridacountry.com/missionspacefunnyvideos.htm

Once the file exists, Firefox has no problem loading QuickTime plugins.  But you can make the problem start happening again by deleting it.
If you see this bug and want to work around it, it isn't enough just to run Safari once.  You also need to delete the pluginreg.dat file in your Firefox profile before running Firefox.

Here's a typical location for the pluginreg.dat (and your Firefox profile):
~/Library/Application Support/Firefox/Profiles/[nnnnnnnn].default/pluginreg.dat
This bug also effects Google Chrome, but (interestingly) not Opera (testing with version 12.01).
Very interestingly, the bug doesn't happen in Firefox if it's run in 32-bit mode.

And from that point forward the com.apple.quicktime.plugin.preferences.plist file exists.  So here's another way to work around this bug:

1) Delete ~/Library/Application Support/Firefox/Profiles/[nnnnnnnn].default/pluginreg.dat.
2) Run Firefox in 32-bit mode just once.
So it appears this bug is in the QuickTime plugin, and is as follows:

On OS X 10.8, the QuickTime plugin is unable to create its com.apple.quicktime.plugin.preferences.plist settings file when it's loaded out-of-process.  So it fails to load correctly if this file doesn't already exist.  Which makes the browser think the plugin is invalid.
Summary: [10.8] QuickTime plugin seen by Firefox as "invalid" until Safari is run at least once → [10.8] QuickTime plugin seen by Firefox as "invalid" until some browser (e.g. Safari) loads it in-process at least once
> On OS X 10.8, the QuickTime plugin is unable to create its
> com.apple.quicktime.plugin.preferences.plist settings file when it's
> loaded out-of-process.

Actually this probably isn't true -- Safari doesn't call any of the
QuickTime plugin's entry points (like NP_Initialize) in-process.

So the problem is more likely to be that the QuickTime plugin is
unable to create its com.apple.quicktime.plugin.preferences.plist
settings file when its entry points are called from a background
process.
Summary: [10.8] QuickTime plugin seen by Firefox as "invalid" until some browser (e.g. Safari) loads it in-process at least once → [10.8] QuickTime plugin seen by Firefox as "invalid" until some browser (e.g. Safari) loads it at least once from a foreground process
Here's the bug report I submitted to Apple:

ML's QuickTime plugin doesn't load in FF until it's been loaded in Safari

On a clean install of Mountain Lion (OS X 10.8), QuickTime plugins
won't load in Firefox or Chrome until they've been loaded at least
once in Safari or Opera (I tested with version 12.01).

The reason for this turns out to be as follows:

The QuickTime plugin's com.apple.quicktime.plugin.preferences.plist
settings file doesn't exist until the QuickTime plugin has created it.
QuickTime will fail to load if this file doesn't exist already and it
can't create it (since it contains all of QuickTime's mimetype
settings).  And it appears that the QuickTime plugin can't create this
file if its entry points (like NP_Initialize) are called from a
background process (i.e. one that isn't currently the foreground
process).

Here's a URL to test with:
http://www.bigfloridacountry.com/missionspacefunnyvideos.htm

This bug was reported at
https://bugzilla.mozilla.org/show_bug.cgi?id=780284, and will be
followed up there.
Whiteboard: rdar://12030142
This issue is still present for Firefox 25 and 26 in OS X 10.9.0 and 10.9.1 and AppleSeed 10.9.2.  Is this an Apple or Mozilla bug?  I feel it is a Mozilla issue since Safari can work just fine with it.  There are two ways to get around this really:

1. Make sure you launch Safai first and play a quicktime video.  Then start firefox and the add-on for Quicktime is listed.

or

2. If you launch firefox first from the menu choose Help --> Troubleshooting Information and click Reset. This also make the plugin load properly.  This item does make me think it's not "really" related to Safari running as why does the firefox reset work when first run does not?  

So still an issue that needs attention.
Per the previous comments, this is an Apple bug and needs their attention.

If you tried to use Quicktime in Firefox before using it in Safari, it won't load, after which we don't try to load Quicktime again unless it changed (needed for performance).
Resetting Firefox means forgetting that Quicktime failed to load previously, so we try loading it again - which now works because the plist file exists.
I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.