724135 - 32-bit plugins marked as invalid in a 64-bit-only build, stay invalid even using universal builds afterward (manual deletion of pluginreg.dat necessary)

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: pluginreg.dat

Whenever a profile was last used with a 32bit arch build and a 64bit tinderbox build is used afterward most of the plugins on OS X get permanently disabled. The problem can only be solved by manually deleting the pluginreg.dat in the profile.

Steps:
1. Download an e.g. Aurora build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/02/2012-02-02-04-20-10-mozilla-aurora/
2. Download an e.g. Aurora TB build: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-aurora-macosx64-debug/1328142155/
3. Start the daily Aurora build and create a new profile
4. Observe about:addons
5. Open the Error Console and evaluate the following code to start Firefox in 32bit mode: 

Components.classes["@mozilla.org/toolkit/app-startup;1"].getService(Components.interfaces.nsIAppStartup).quit(Components.interfaces.nsIAppStartup.eAttemptQuit | Components.interfaces.nsIAppStartup.eRestart | Components.interfaces.nsIAppStartup.eRestarti386);

6. Observe about:addons and close Firefox
7. Start the Tinderbox build of Aurora
8. Observe about:addons

As you will notice in step 8 most of your installed plugins have been disabled. Afterward it is not possible to reactivate those plugins anymore, except by manually deleting the pluginreg.dat. But even that doesn't help if you directly start the tinderbox build again. A default build with both architectures have to be run first to get rid of the problem.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Turns out the real problem is that 64-bit-only builds can't find 32-bit plugins.  Which isn't really a bug (since 64-bit-only builds aren't intended for general use).

But we do need to ensure that all builds intended for general use (including ESR builds) *are* Intel-universal.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

STR for this bug:

1) Download or make a 64-bit-only build.  For example
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-aurora-macosx64-debug/1328142155/firefox-12.0a2.en-US.mac64.dmg
from comment #0.

2) Delete pluginreg.dat from your FF profile (e.g.
~/Library/Application
Support/Firefox/Profiles/nnnnnnnn.default/pluginreg.dat).

3) Run the 64-bit-only build and do about:plugins.

4) Notice that only 64-bit plugins show up in the list.

   Notice also that all your 32-bit plugins will be listed in the
   [INVALID] section at the end of pluginreg.dat.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Steven, let me reopen the bug for the remaining open issue. Why will those 32bit plugins not enabled anymore even you start an universal build afterward? Do we really want to force users to delete the pluginreg.dat file in the profile?

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Ordinary users don't use 64-bit-only builds (or 32-bit-only ones either).

I still think this bug is invalid.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Actually, when do we update the pluginreg.dat file?

Comment 6

[Steven Michaud [:smichaud] (Retired)]

> Actually, when do we update the pluginreg.dat file?

I don't know, and it'd be rather a lot of work to find out.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Steven Michaud from comment #6)
> > Actually, when do we update the pluginreg.dat file?
> 
> I don't know, and it'd be rather a lot of work to find out.

I think Benjamin will be able to help out here.

Comment 8

[Benjamin Smedberg]

http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginHost.cpp#2836

We compare the current architecture with the last architecture of pluginreg.dat and only use it if they match. In this case "64-bit only" and "64-bit universal" have the same architecture, even though they can load a different set of plugins. I don't think this bug is worth fixing.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks Benjamin. I have updated the summary of the bug to reflect the issue I was talking about in the first comment.

Marking as wontfix based on comment 8.