524338 - [10.6] Add dock tile plugin support to allow entering safe mode without command line

Status: NEW

(Firefox :: Shell Integration, enhancement)

Description

[Tom Dyas]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: 

Snow Leopard added a new feature called "dock tile plugins" which allow an application to include a plugin bundle loaded by the Dock to supply menu entries for the Dock menu *before* the application is launched. This lets us provide menu entries like "Open in Safe Mode" so that users need not drop to the command line to put Firefox into safe mode.

Once the application has launched, the applications overrides the dock tile plugin and the relevant entries will no longer appear.

Reproducible: Always

Comment 1

[Tom Dyas]

Attachment: Dock Tile Plugin v1

This patch adds support for a Firefox dock tile plugin.  The menu entries and/or features need to be finalized and the strings localized.

Comment 2

[Phil Ringnalda (:philor)]

I was going to mention bug 393327, but I guess you know about that, since you attached your plugin there earlier.

Comment 3

[Tom Dyas]

I opened a new bug since bug 393327 deals with "safe mode" only while I'd like to start a discussion in this patch about what other menu items may be useful in the Dock menu prior to Firefox launching (e.g., accessing the profile manager).

Comment 4

[Phil Ringnalda (:philor)]

A profile manager menuitem's unlikely fly, since it's been intentionally hidden since the pre-1.0 days when there was talk about completely removing it and requiring that you specify a profile path on the commandline if you wanted to use more than one.

I wonder if this would fit better in Toolkit: Startup? I'd certainly like to see it built there, where Tb could have it for free :)

Comment 5

[Tom Dyas]

(In reply to comment #4)
> A profile manager menuitem's unlikely fly, since it's been intentionally hidden
> since the pre-1.0 days when there was talk about completely removing it and
> requiring that you specify a profile path on the commandline if you wanted to
> use more than one.

Ah.  Could always just make it visible in debug builds then (or not at all if that is the decision).  

> I wonder if this would fit better in Toolkit: Startup? I'd certainly like to
> see it built there, where Tb could have it for free :)

Would that make it applicable to all XULRunner applications?  If so, "-safe-mode" might not be applicable to all of them.  Also, to enable the dock tile plugin, a key must be added to the application's Info.plist, which is specific to each application so a patch would still be necessary to Thunderbird.

Comment 6

[Benjamin Smedberg]

-safe-mode is applicable to all XULRunner applications. Please do not include anything relating to the profile manager (it will be going away).

How do dock tile plugins work? Are they shared libs loaded into the address space of finder, or are they separate little applications? I'm concerned about the l10n impact of this kind of change, although it would be really great UI and we should find a way to do it if possible.

Comment 7

[Tom Dyas]

(In reply to comment #6)
> -safe-mode is applicable to all XULRunner applications. Please do not include
> anything relating to the profile manager (it will be going away).

ok

> How do dock tile plugins work? Are they shared libs loaded into the address
> space of finder, or are they separate little applications? I'm concerned about
> the l10n impact of this kind of change, although it would be really great UI
> and we should find a way to do it if possible.

When an application is added to the Dock, the SystemUIServer process looks into the application's bundle to see if it has a dock tile plugin.  SystemUISever loads this plugin into its address space. (Finder is not involved.)  When a user requests the dock menu for the application, SystemUISever calls the "dockMenu" method of the plugin instance.

The plugin can also "badge" the application's icon even when the application is not running with a number (e.g., for unread messages, etc.)

l10n would be done the Mac OS X way by including the translated string in a .strings file in the plugin's bundle.

Comment 8

[Axel Hecht [:Pike]]

I disagree on the l10n part here, at least for the source of it. The plugin should read a plain text file from a known good location, and that text file needs to be create by the repackaging process out of one of our known mozilla l10n file formats.

"Known good location" is likely not xulrunner, but the app bundle, even though the plugin is probably shipped as part of xulrunner, for xulrunner apps.

Comment 9

[Tom Dyas]

(In reply to comment #8)
> I disagree on the l10n part here, at least for the source of it. The plugin
> should read a plain text file from a known good location, and that text file
> needs to be create by the repackaging process out of one of our known mozilla
> l10n file formats.
> 
> "Known good location" is likely not xulrunner, but the app bundle, even though
> the plugin is probably shipped as part of xulrunner, for xulrunner apps.

Can you point me at an example of such a file (or instructions on how to integrate such a file into the l10n build system) so I can switch the code to using it?  I'm not familiar at all with the Mozilla l10n repackaging process.

Comment 10

[Nomis101]

I share the concerns about the l10n part here. Normally localizers need *.dtd / *.properties files. I remember there was the same problem with localizing the old PrintPDE plugin (see Bug 268309). And I'm not sure if the *.strings file will be recognized from the l10n dashboard (I think it will not).
But in general I like the idea.

Comment 11

[Axel Hecht [:Pike]]

We have tons of .properties or .defines files in the tree. You likely need to post-process it, scripts for that should either be shell scripts (if simple enough) or in python these days.