57830 - Profile Migration causes wrong default Sidebar tab

Status: VERIFIED INVALID

(Core Graveyard :: Profile: Migration, defect, P1)

Description

[johng]

When you migrate a 4.x profile, the default list of Sidebar tabs does not
correctly choose the right tab to be default.

win95 build from 10/23

For example, on Netscape commercial builds, the default list (as detailed at the
beginning of bugscape bug 2847) calls for the News tab to be open by default.
However, the last tab, the Today's Tips tab (earlier know as Sidebar Today) is
incorrectly open by default.

We need urgent QA help to define exactly what happens and when on the various
platforms.  cc'ing shrir who is the Sidebar QA lead and assigning the bug to
profile migration so their engineer and QA lead can look at this, too.

Comment 1

[johng]

keyword rtm

This has a huge impact on our traffic forecasts and business model.  Depending
on exactly when the user runs into this bug, this could be a pull off the wire
thing.

Comment 2

[Paul Chen]

Actually, I just found out that for the windows build, the install is using the
wrong localstore.rdf. My windows commercial branch build contains the correct
localstore.rdf. I would guess somehow installer is using the wrong one.

Comment 3

[Daniel Veditz [:dveditz]]

dbragg is out today, so if you're looking for immediate action you may want to
assign to someone else. hard to see how migration could be the culprit since
this file is not migrated.

How could the install be using the "wrong" localstore.rdf? This file is
identical between mozilla and ns.

Comment 4

[Paul Chen]

dveditz, not anymore. I had split them to make the default tab change for
commercial only. Wouldn't want mozilla localstore.rdf to reference a panel only
availble in a commercial build now, would we?

Comment 5

[Daniel Veditz [:dveditz]]

A ha! found a culprit to pin this on -- reassigning. When you change files that
should get delivered you need to update the package lists.

In this case the three ns/xpinstall/packager/packages-<foo> files need to have
the localstore.rdf file added to the [deflenus] section to overwrite the
corresponding one copied from the Mozilla build and packages-<foo> lists.

At least, this is enough of a safe fix to be checked into the RTM branch. In
addition it looks like profile migration pulls files directly from
defaults/profile rather than defaults/profile/<locale>. That part of the bug
should be fixed on the trunk and be assigned to Tao. Maybe we need a separate
bug for that case.

Comment 6

[tao]

Comments:

1. Regarding the maintenance of packager-*, module owners is responsible of
   adding new files to langenus or deflenus.
2. In migrating a profile (especially from 4.x), defaults/profile/* is
   used since profile locale info might not be available yet. This is
   especially true in migrating 4.x profile.

Comment 7

[don]

Paul ...

Comment 8

[Alec Flett]

adding dbragg and sspitzer to the CC, masters of the profile migration process.

Comment 9

[lchiang]

johng: would you consider this a stop ship?  I'm just trying to get this on the 
radar of PDT early.

Comment 10

[Daniel Veditz [:dveditz]]

Attachment: Patch to add localstore.rdf

Comment 11

[Daniel Veditz [:dveditz]]

Without this patch (which simply explicitly adds the *commercial* 
localstore.rdf to the *commercial* deflenus.xpi -- this should be a bugscape 
bug) we ship the Mozilla version of localstore.rdf instead of the branded one.

Comment 12

[tao]

r=tao for (dveditz's patch:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=17965)
low risk; high reward.

Comment 13

[Paul Chen]

I've created bugscape 3042 for this bug because it's really an ns installer problem.

Comment 14

[Paul Chen]

Resolving invalid because the bug is really an installer problem, also have
logged bugscape 3042 as the new form of this bug.

Comment 15

[Daniel Veditz [:dveditz]]

This bug is not invalid because you forgot to update the install package lists 
when you created a new file, it's invalid because it's a commercial problem not 
a Mozilla problem.

Comment 16

[Paul Chen]

Ok, ok, uncle. dveditz is correct, what I should of said was that this bug is
invalid because it is a commercial installer issue.

Comment 17

[John Unruh]

Verified invalid, since bugscape 3042 is open.