This is a tracking bug for work needed to complete to Improve Windows Integration. To implment this, we should support the context-menu "Configure..." option on the Start menu internet application (to open prefs rather than IE's Internet Options).

->law

what's the priority and target for this one? are we still planning to get this in for MachV?

This patch does 3 things: 1. Adds a new localizable string to nsINativeAppSupportWin.idl and splash.rc. 2. Adds code to nsWindowsHooksUtil.cpp's setWindowsXP routine to set the appropriate windows registry values to that the context menu for Mozilla (when it is the default internet app) has "Preferences" which opens pref.xul. 3. Code added to pref.xul's onload handler to handle the case where prefs is already open (it focuses the existing pref window and closes the redundant one before it appears). One issue: There is no mechanism for doing localizations in splash.rc. We cannot get the string from a properties file. I don't relish the thought of creating a separate mozilla-resources.dll and putting the resources there. That would require substantial build system work, not to mention complicating the life of translators. The alternative is to simply not specify a string, in which case it defaults to "Properties" (or the localized equivalent, per Windows localization). Does anybody have strong objections to us going that route?

I decided to exploit the Windows "feature" whereby a localized string can be placed in the context menu (rather than indirectly via a module resource). That enables me to fetch it from a properties file. Ben tested this on his WinXP system and I think it is ready to land. Reviews, please.

sr=hyatt

Comment on attachment 69149 [details] [diff] [review] Revised patch to use localized pref menu label. r=ben@netscape.com

does this bug also cover the ability to make Mozilla the default Newsreader?

No; there are other bugs for that, I believe.

this one has landed

According to bug 150512 the preferences don't actually open because of a missing space. That's probably worse than not doing this at all.

Dan, why did you reopen this when there is already a separate bug for the specific defect?

Nav triage team: nsbeta1-

regression caused by this checkin was fixed a long time ago under another bug. Reverting to FIXED