Right now we use the string "Gecko" to call gnome_program_init() in the GNOME helper app code. It turns out that this string can show up on the GNOME panel task list when it does window grouping. We should use the real application name instead.

I seem to recall an existing bug on this....

This should be more straightforward, but here's why it's not. We are unable to do anything with chrome:// urls from inside the nsOSHelperAppService ctor, because we are already inside the ChromeRegistry's Init method (or more accurately, CheckForNewChrome()). The nsOSHelperAppService is being instantiated to determine the mimetype for chrome.rdf (sorry I don't have the full stack for this in front of me). So to get around this service creation reentrancy problem, I just made GNOMERegistry initialize lazily. The only downside of this patch is that we don't (afaik) communicate clearly to embedders that they should set brandShortName to something unique.

cc bsmedberg in case he has any thoughts on the chrome registry issue I mentioned.

Comment on attachment 143914 [details] [diff] [review] patch >Index: nsGNOMERegistry.cpp >+ // Only start up once. >+ if (gInitialized) >+ return; >+ >+ gInitialized = PR_TRUE; so if initialization fails the first time through here, then we won't try again. that seems reasonable. > char *argv[1] = { "gecko" }; >+ _gnome_program_init(NS_ConvertUTF16toUTF8(appName).get(), "1.0", >+ _libgnome_module_info_get(), 1, argv, NULL); so, it's still okay for argv to reference "gecko" ? perhaps we should fail if brandShortName is not set? that way embedders will be force to set it? or maybe the debug warning is good enough? sr=darin

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

ick: why do we need the OShelperappservice to determine the mimetype of chrome.rdf? Client already knows that it's a rdf+xml type... is that just an inbred requirement of necko?

(In reply to comment #6) > ick: why do we need the OShelperappservice to determine the mimetype of > chrome.rdf? Client already knows that it's a rdf+xml type... is that just an > inbred requirement of necko? nsOSHelperAppService implements nsIMIMEService... for .rdf it uses a hardcoded list, but of course the constructor must be called before that. As for why it needs this... the rdf service does, iirc, check the mime type it gets and checks if it is the type it expects (text/rdf iirc). some channels need the mimeservice to get the type.

This bug has a patch that has review and superreview - why not get it in? :-)

Why not check in this one? The similar code in bug 225148 is already committed.

bryner, is it OK to commit it to 1.8b2?

When I check in the patch, it's name is "Mozillz-bin". But I think it should be "Mozilla". When we launch firefox, the group name is "Firefox". there is a bug when firefox's group name is "Firefox-bin". see https://bugzilla.mozilla.org/show_bug.cgi?id=284337

This patch was never checked in. Is this still wanted?

This patch works for Mozilla 1.7, but it seems CVS HEAD had fixed this problem in another way. Seamonkey displays seamonkey-bin in task panel, firefox displays Firefox (see bug 321790) The name in task panel didn't change before and after applying this patch.

So, I take it, nothing needs to be checked in here, removing [checkin needed] from whiteboard.