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

Status: VERIFIED FIXED

(SeaMonkey :: Startup & Profiles, defect)

Description

[Frank Wein [:mcsmurf]]

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.

Comment 1

[Frank Wein [:mcsmurf]]

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.

Comment 2

[Tobias Fischer]

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.

Comment 3

[Frank Wein [:mcsmurf]]

The History import seems to work fine when setting the NO_EM_RESTART=1 environment variable.

Comment 4

[Marco Bonardo [:mak]]

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.

Comment 5

[Ian Neal]

Confirming blocking.

Comment 6

[[e-mail]]

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?

Comment 7

[Robert Kaiser]

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...

Comment 8

[Robert Kaiser]

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)?

Comment 9

[Frank Wein [:mcsmurf]]

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).

Comment 10

[Shawn Wilsher :sdwilsh]

(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).

Comment 11

[Marco Bonardo [:mak]]

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

Comment 12

[Robert Kaiser]

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.

Comment 13

[Frank Wein [:mcsmurf]]

(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.

Comment 14

[Frank Wein [:mcsmurf]]

(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

Comment 15

[Shawn Wilsher :sdwilsh]

I can't think of enough details of the bug that might have fixed it.  I thought mak had fixed something like this though...

Comment 16

[Frank Wein [:mcsmurf]]

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.

Comment 17

[Shawn Wilsher :sdwilsh]

Ah, yeah - that would fix it since we'll always flush when needed.  I thought there was another fix that fixed it though...

Comment 18

[Robert Kaiser]

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).

Comment 19

[Frank Wein [:mcsmurf]]

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/?

Comment 20

[Tobias Fischer]

Tested on two different Systems running W2k and WinXP, History-Import works well now.