Last Comment Bug 484175 - History Import from SeaMonkey 1.1.x is not working (related to places?)
: History Import from SeaMonkey 1.1.x is not working (related to places?)
Status: VERIFIED FIXED
: relnote
Product: SeaMonkey
Classification: Client Software
Component: Startup & Profiles (show other bugs)
: Trunk
: All All
: -- critical with 2 votes (vote)
: seamonkey2.0b1
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 483980
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-19 05:10 PDT by Frank Wein [:mcsmurf]
Modified: 2009-09-03 06:26 PDT (History)
10 users (show)
kairo: blocking‑seamonkey2.0b1-
kairo: blocking‑seamonkey2.0b2+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Frank Wein [:mcsmurf] 2009-03-19 05:10:32 PDT
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] 2009-03-19 05:20:24 PDT
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 2009-03-19 05:49:04 PDT
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] 2009-03-19 07:39:03 PDT
The History import seems to work fine when setting the NO_EM_RESTART=1 environment variable.
Comment 4 Marco Bonardo [::mak] 2009-04-21 08:15:10 PDT
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 2009-06-02 06:04:55 PDT
Confirming blocking.
Comment 6 neil@parkwaycc.co.uk 2009-06-02 09:06:33 PDT
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 2009-06-11 10:03:42 PDT
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 2009-07-07 12:54:53 PDT
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] 2009-07-07 13:01:30 PDT
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 2009-07-07 13:28:08 PDT
(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] 2009-07-07 15:32:22 PDT
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 2009-07-08 08:19:10 PDT
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] 2009-07-11 16:26:38 PDT
(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] 2009-07-11 16:34:13 PDT
(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 2009-07-11 18:28:33 PDT
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] 2009-07-12 11:57:55 PDT
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 2009-07-12 12:08:09 PDT
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 2009-07-14 05:55:07 PDT
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] 2009-08-13 09:03:21 PDT
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 2009-09-03 06:26:00 PDT
Tested on two different Systems running W2k and WinXP, History-Import works well now.

Note You need to log in before you can comment on or make changes to this bug.