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. > > - 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... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
