Closed Bug 484175 Opened 11 years ago Closed 11 years ago

History Import from SeaMonkey 1.1.x is not working (related to places?)

Categories

(SeaMonkey :: Startup & Profiles, defect, critical)

defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
seamonkey2.0b1

People

(Reporter: mcsmurf, Unassigned)

References

Details

(Keywords: relnote)

To reproduce:
0. Create a SeaMonkey 1.1.x profile and use it to get a few entries in History
1. Fetch&install a current comm-central build
2. Move your current SeaMonkey 2 profile folder to another place and start the comm-central build
3. In the upcoming migration dialog import your SeaMonkey 1.1.x profile

Results:
The history.dat file has been copied to the new profile folder, but the History is empty. The file creation date of history.dat is 5 seconds before the file creation date of places.sqlite. The debugger shows that nsNavHistory::ImportHistory has been called after the migration, but it looks like this function did not work properly then. When I quit SeaMonkey 2, delete the places.sqlite file and start up SeaMonkey 2 again, the import works fine.
BTW: History import seems to work fine when importing a SeaMonkey 1.1.x profile with a Firefox 3.5 (1.9.1 repository) nightly.
I can confirm this issue, tested with SM 1.1.14 (yo, will update soon) and todays SeaMonkey 2.0b1pre Windows Nightly. 

At the first Start of SM 2.0pre the history.dat was copied into the Profile folder, but not into the places.sqlite. Second Start with previous deleted places.sqlite import the history. Hmm.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The History import seems to work fine when setting the NO_EM_RESTART=1 environment variable.
Flags: blocking-seamonkey2.0b1?
notice there are differences between places code that imports history on trunk and 1.9.1 branch.
Btw places should look for history.dat at every init, so that looks strange.
Confirming blocking.
Flags: blocking-seamonkey2.0b1? → blocking-seamonkey2.0b1+
OK, so what happens is this:
1. XRE discovers no running instance (or -no-remote used)
2. XRE discovers a usable profile
3. XRE starts all services in the profile-after-change category
   which includes places sync
   which starts nsNavHistory
   which imports history.dat
   but doesn't appear to save it...
4. XRE asks EM to start up
5. EM decides it needs a restart
   which presumably bypasses the frecencies recalculation event?
Flags: blocking-seamonkey2.0b1+ → blocking-seamonkey2.0b1?
Flags: blocking-seamonkey2.0b1? → blocking-seamonkey2.0b1+
Can we get some traction on this? What can we do to fix it? Who can take this on? This blocks our SeaMonkey Beta, we just can't let it [l|d]ie around here...
Target Milestone: --- → seamonkey2.0b1
Shawn, any idea why what Neil described in comment #6 can happen, what could have triggered it or how we could solve it (preferably the latter, of course)?
references to two related bugs: Bug 450290, Bug 449640 (Neil told me those two bugs "caused" this bug here/have something to do with the bug).
(In reply to comment #8)
> Shawn, any idea why what Neil described in comment #6 can happen, what could
> have triggered it or how we could solve it (preferably the latter, of course)?
I thought mak fixed something like that recently.  He's the one who knows the import code best though (cc'ing him).
i don't know the functionality of XRE enough to express an idea, i discussed a bit with Neil some time ago, but, no idea. I think due to how restart is handled sync service is not executing the final sync. we should know the exact sequence of events and notifications in that area
OK, I just tried a few builds, and this is no regression - not just 2.0a3, even builds from January show the bug and a build from December 10, two days after landing places history in SeaMonkey, also shows it. This has been there from the beginning.
The workaround is to quite SeaMonkey, delete places.sqlite manually and start SeaMonkey again, which will import the old history successfully.
(In reply to comment #10)
> (In reply to comment #8)
> > Shawn, any idea why what Neil described in comment #6 can happen, what could
> > have triggered it or how we could solve it (preferably the latter, of course)?
> I thought mak fixed something like that recently.  He's the one who knows the
> import code best though (cc'ing him).

With a current comm-central/mozilla-central SeaMonkey build this bug still occurs.
(In reply to comment #13)
> With a current comm-central/mozilla-central SeaMonkey build this bug still
> occurs.

I must correct myself, it does seem to work and the bug no longer occurs :)!
Shawn or Mak: Do you have a bug # which might have fixed this? Wondering if this is something which could be ported to the 1.9.1 branch
I can't think of enough details of the bug that might have fixed it.  I thought mak had fixed something like this though...
Ok, found it after taking a look at hg pushlog and doing a few builds: Bug 483980 fixed this bug here (when using comm-central/mozilla-central). So I guess it would be nice to have that bug on 1.9.1 branch if possible.
Depends on: 483980
Ah, yeah - that would fix it since we'll always flush when needed.  I thought there was another fix that fixed it though...
By decision in this week's status meeting, we're pushing this out to Beta 2 and relnote it for Beta 1. We hope that bug 483980 will get into 1.9.1 ASAP, but we will not hold this first Beta for it, as we're already quite late for it and it looks like we don't get a load of dupes, probably because history is not that high priority for people who are only switching to places (I guess it ranks higher for those who get used to the new location bar matching).
Severity: normal → critical
Flags: blocking-seamonkey2.0b2+
Flags: blocking-seamonkey2.0b1-
Flags: blocking-seamonkey2.0b1+
Keywords: relnote
OS: Windows XP → All
Hardware: x86 → All
This should be fixed now. Someone can test this with a current nightly build from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-1.9.1/?
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Tested on two different Systems running W2k and WinXP, History-Import works well now.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.