Closed Bug 533729 Opened 15 years ago Closed 15 years ago

Migration Assistant tab appears whenever TB is started even though tab was previously closed

Categories

(Thunderbird :: General, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: jknauth, Unassigned)

Details

(Whiteboard: [support])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 GTB6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0

I installed TB 3.0 into a new directory (custom install), but let it use my TB 2 profile.  When I start TB 3.0, first just the Input tab appears plus a popup to enter the password for my POP server, as with TB 2.  After I enter the password, immediately a Migration Assistant tab is created.  I thought I had already installed and migrated.  Why does MA keep showing up every time I start TB 3.0?  I can find no setting to turn it off.  I have to assume there is something somewhere that considers my migration incomplete and the MA tab keeps reappearing even though I always close it.

Reproducible: Always

Steps to Reproduce:
1.Start TB (Inbox tab appears)
2.Enter POP password
3.Migration Assistant tab appears beside Inbox tab
4.Close MA tab
5.Close TB
6.Restart TB, enter POP passwaod, and the MA tab reappears   
Actual Results:  
See above

Expected Results:  
The Migration Assistant tab should not appear every time TB is started.  It should automatically appear only after the initial install and be accessible via Help after then, if required.

I am running Vista 64.  In the status area at the bottom of the MA tab is a "Determining which messages to index" message.  I tried turning off indexing, but that didn't solve the problem of the MA tab constantly appearing.
What are the values of :

profile.confirm_automigration
profile.force.migration
profile.migration_behavior
profile.migration_directory

in your prefs.js file ?
Thanks.  Here's what is in my prefs.js:

profile.confirm_automigration     default  boolean  true
profile.force.migration           default  string
profile.migration_behavior        default  integer  0
profile.migration_directory       default  string

But your question made me remember to look into my (pretty small)
user.js, which has been unchanged for many releases of Thunderbird.  I
found if I renamed that file, the problem disappeared.  I then narrowed
down the problem line to the following in that file:

    user_pref("mailnews.ui.threadpane.version", 5);

If I commented out that line, the problem disappeared.  None of the
other user.js lines caused it.  I also tried a user.js file containing
only that line.  The problem came and went depending on whether the
statement was active or commented out.

I see the default for this option is now 7.  I don't recall why I had 5
specified.  Anyway, it looks like that was the problem and using the 7
default via prefs.js seems to work fine for me, so I have removed the
line from user.js.

The constant MA tab was a pretty interesting symptom and not not one I
would have suspected from my user.js lines.  Live and learn.
Thanks for investigating.

marking new, maybe we should fix this before we push 3.0 to all 2.x users ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [support]
Nothing to fix - without actually knowing it, Jeffrey was asking us to do just what we were doing. Showing something only once, only for upgrades from a previous version, requires having a pref that you know was set to one value in the previous version, and setting it to another value once you've done the one time thing. By setting it to our "before" value in user.js, he was saying "at every startup, pretend I just came from 2.0."
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.