* Mike Hommey ([EMAIL PROTECTED]) wrote: > On Mon, Feb 19, 2007 at 05:48:45PM -0500, Eric Dorland <[EMAIL PROTECTED]> > wrote: > > * Mike Hommey ([EMAIL PROTECTED]) wrote: > > > merge 411475 411479 411483 411493 411505 411531 > > > severity 411475 serious > > > thanks > > > > > > Hi, > > > > > > These issues are, as far as I can see, all from the same origin: the fix > > > for bug #408883. This is very unfortunate, and I see the following > > > choices to solve the issue: > > > > I'm shocked that this change had all these negative side effects. > > > > > - Hack the profile manager so that it tries to use the firefox profile > > > if it exists, like it already does with very old profiles that were in > > > ~/.firefox. > > > > This is probably a good idea in any case. > > The downside of this is that if people create a profile with iceweasel > and later try firefox, the profile won't be shared.
Good point. > > > - Hack the profile manager so that it doesn't display "Firefox" but > > > "Iceweasel", without involving a modification of the nsXREAppData like > > > has been done in the fix for #408883. > > > > Basically the problem is that the name field in nsXREAppData is > > overloaded. There should be a display name field in that struct for > > this situation. I think I'll work on a fix from that approach. > > ... or the other way around: a "profile directory base" field. By > default, this is .$vendor/$product (both $vendor and $product being > lowered-case). When there is no $vendor, it's on .$product. > This rule also applies to xulrunner applications, so we have to think > about something that will still work when firefox will be based on > xulrunner... Well how would that be different? There's also other things that use this name field in non display ways. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6
signature.asc
Description: Digital signature
