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

VERIFIED FIXED in seamonkey2.0b1

Status

SeaMonkey
Startup & Profiles
--
critical
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: mcsmurf, Unassigned)

Tracking

({relnote})

Trunk
seamonkey2.0b1
relnote
Bug Flags:
blocking-seamonkey2.0b1 -
blocking-seamonkey2.0b2 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
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

9 years ago
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
(Reporter)

Comment 3

9 years ago
The History import seems to work fine when setting the NO_EM_RESTART=1 environment variable.
(Reporter)

Updated

9 years ago
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.

Comment 5

8 years ago
Confirming blocking.
Flags: blocking-seamonkey2.0b1? → blocking-seamonkey2.0b1+

Comment 6

8 years ago
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?

Updated

8 years ago
Flags: blocking-seamonkey2.0b1? → blocking-seamonkey2.0b1+

Comment 7

8 years ago
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...

Updated

8 years ago
Keywords: regression, regressionwindow-wanted
Target Milestone: --- → seamonkey2.0b1

Comment 8

8 years ago
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)?
(Reporter)

Comment 9

8 years ago
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

Comment 12

8 years ago
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.
Keywords: regression, regressionwindow-wanted
(Reporter)

Comment 13

8 years ago
(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.
(Reporter)

Comment 14

8 years ago
(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...
(Reporter)

Comment 16

8 years ago
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...

Comment 18

8 years ago
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
(Reporter)

Comment 19

8 years ago
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
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 20

8 years ago
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.