290763 - "Links from other applications" resets to default after using Latest-Trunk

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[Thomas K. (:tom)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050415 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050415 Firefox/1.0.3

This has happened a few times (for 20050407, 20050416, and some other
latest-trunk).  I kill off firefox aviary nightly, and run the unzipped version
of latest-trunk.  Once I come back to aviary nightly, things are fine for a
while, till I click a link from an external program.  It opens in the latest
tab, instead of what I had set the pref to, "a new tab in the latest window",
the most sane option.  This happened after I used the 07 trunk and I didn't
associate the two for a while, until it happened again today.

Reproducible: Always

Steps to Reproduce:
1. Set, in latest-aviary installed (this is how i have it setup) the "Open links
from other applications in:" option to "A new tab in the most recent window"
2. Grab and extract firefox latest-trunk
3. Run firefox latest-trunk
4. Exit firefox latest-trunk and open up aviary again.
5. Click a link from another window (mIRC, AIM/MSN/whatever)
6. Notice it doesn't open in a new tab but the current tab

Actual Results:  
it opened in the current tab, which has caused data loss (gmail)

Expected Results:  
not forgotten the setting and opened in a new tab

Currently I'm on aviary 20050415 and it occurred with trunk 20050416 (i think,
it was recent).

Comment 1

[:Gavin Sharp [email: [e-mail]]]

I see this too, but I haven't taken the time to try to figure out what happens.

Comment 2

[Tristor]

Setting severity to major, you losing a letter you are working on in gmail
because a tab opened on top of it is not data loss.  Data loss would be if this
bug caused either corruption of something in your profile, or you actually lost
something (bookmarks, extensions, something).

Comment 3

[Thomas K. (:tom)]

After filing this bug, Aviary wouldn't start.  Well, it'd start, but it showed
the green update icon all the way left (right next to help), showed a blank bar
for the bookmarks bar, and stated "Mozilla Firefox Start Page - Mozilla Firefox"
as the application TITLE.  I was unable to use this browser.

So now I've switched to latest trunk for my main browser, and miraculously I can
use my old profile again.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050417
Firefox/1.0+

Comment 4

[Tristor]

Sharing profiles between branch/aviary and trunk builds is generally a bad idea...

Comment 5

[Thomas K. (:tom)]

Thanks for that intelligent comment Tristor!  To make sure noone thinks _I_ am
the idiot in this situation, it's time for background.

Tristor triages bugs.  He often begs people to help him, and apparently I'm one
of the few who uses WinXP.  He asks me to grab latest trunk (links me direct to
the ftp, and doesn't tell me anything about not sharing profiles) and directs me
to the bug and fixes the test.  This worked before, I was able to still use my
profile afterward.  Now apparently it doesn't.

I am sad, because PrefWindow V5 sucks (I can't specify _which_ javascript things
to disable, just what Ben believes is annoying I guess).  Hopefully I'll be able
to transform my profile back to Aviary 1.0.1 sometime soon :(

Comment 6

[Tristor]

(In reply to comment #5)
> 
My apologies for not specifically saying not to mix profiles, I thought it was a
given.  If you are wanting to 'repair' your profile, have you tried doing the
'fix' that is generally applied whenever profile corruption occurs?  That is,
making a new profile, and copying all the goodies over?

As to the bug, I am unable to confirm it, because I don't have the right setup
to do so.  I will see about doing something on another computer (running w2k)
and see if I can reproduce.

Comment 7

[Brendan Eich [:brendan]]

I've seen this too, and there's never been a migration option from "branch
Firefox profile" to "trunk" -- nor should there be from 1.0.x to 1.1, AFAIK. 
This looks like a straight-on bug.  Who should own it?

/be

Comment 8

[:Gavin Sharp [email: [e-mail]]]

I suspect this was caused by the fix for bug 287086. The pref
(browser.link.open_external) simply gets removed from the user's prefs.js after
running a trunk build, so it reverts to the default when you run a branch build
again.

Comment 9

[Thomas K. (:tom)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050502
Firefox/1.0+

I suppose it's kind of pointless to fix this bug, since it's basically sharing
profiles which isn't reccomended.  I have no idea why 1.0.3 won't use my profile
now, and it's kinda bad too because of all the new glitches indroduced by recent
bug fixes.  I wouldn't mind if it was marked WONTFIX, but I won't mark it that
(in case you actually want to be awesome and give me a way out of being forced
to use trunk).

Comment 10

[Mike Connor [:mconnor]]

Basically, on the upgrade, you end up with a user-set pref that matches the
default, so the prefservice doesn't keep this stored.  Then of course when you
go back to 1.0 you then end up with the default.

This isn't new, or isolated to this pref, its a longstanding example of how our
prefservice works.  Changing the prefservice on trunk (aside from this being a
frozen interface) would let us work better for the 1.0->1.1->1.0 pattern, but if
a 1.1 user goes to 1.0 and their pref matches the old default, we'll still hit
this.  The only alternative that's somewhat viable is to change the pref name
and migrate, but that's not a road I want to go down for every pref default we
change.

Note that a simple upgrade from 1.0 to 1.1 will not have any problems of this
nature, so we're only really looking at the small portion of our userbase that's
going to switch back and forth between major versions.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

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

Comment 12

[Jared Wein [:jaws] (please needinfo? me)]

It isn't worth spending our time to fix this bug since it doesn't apply to currently released Firefox.