568706 - Empty dialog opened by Profile Manager with old xpti.dat or compreg.dat

Status: RESOLVED DUPLICATE of bug 525154

(SeaMonkey :: Startup & Profiles, defect)

Description

[Jens Hatlak (:InvisibleSmiley)]

Attachment: empty dialog in Profile Manager

I recently found that starting my trunk nightly with the Profile Manager and selecting a profile to be used resulted in an empty dialog being opened (see attached screen shot) when selecting Start SeaMonkey for the second time (the first time it did nothing). Exiting the empty dialog is only possibly by means of the window controls (top right X). The Profile Manager itself is affected, too: The Exit button does nothing.

After the empty dialog has been closed using the window control (top right X), doing the same to the Profile Manager will start SeaMonkey with the selected profile.

I fixed the issue for me by deleting components/xpti.dat in the application directory. Using the internal update mechanism I installed a new trunk nightly meanwhile (20100526 -> 20100527) but that didn't help.

KaiRo: I've only made the connection to xpti.dat because I remembered a checkin of yours (<http://hg.mozilla.org/comm-central/rev/b194818d3521>, unfortunately with a typo regarding the file name). Since that one had no bug number mentioned in the checkin comment I chose to open this bug so that it exists, together with the screen shot. Feel free to resolve this bug as needed, e.g. duplicate of the bug that lead to your checkin, or WONTFIX or whatever makes sense. I really don't know whether further investigation is needed (e.g. if we maybe miss some strings on the SM side to make the empty dialog tell something useful) or whether you know already what's up with this. Maybe in the end this even needs to become a Toolkit bug.

I'll attach a diff of the old and new xpti.dat files.

Comment 1

[Jens Hatlak (:InvisibleSmiley)]

Attachment: xpti.dat diff

Comment 2

[Robert Kaiser]

I know, I've been a bad boy with that checkin comment. Sorry. It's been bug 562047, and I don't know how we can do anything more there. I'm not sure it's xpti.dat, though, I'd bet on compreg.dat being actually the cause.
Both are autogenerated files though, and all we can do is remove them on update/install as we do now. If you do manual builds and copy one over the other, we can't help.

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #2)
> I don't know how we can do anything more there.

Well, maybe we could try to find out what is supposed to be in that empty dialog and why it is empty (and non-functional, the buttons do nothing)...

> I'm not sure it's xpti.dat, though

Removing xpti.dat in the application directory was all that was needed to work around the bug for me. But maybe there are dependencies like "if xpti.dat is gone, recreate compreg.dat" or something, I didn't check that.

> Both are autogenerated files though, and all we can do is remove them on
> update/install as we do now.

The fix in Bug 562047 seems to be for the installer only. I'm not using the installer.

> If you do manual builds and copy one over the other, we can't help.

I didn't copy one over the other (why would I?). I'm only using ZIP files and the internal update (AUS). When using ZIP files, I first remove *all* files in the application directory, then extract the archive. I'm only doing that when I cannot update the nightly anymore (e.g. because it crashes at startup). Obviously in that case the problem cannot appear unless the nightly itself is broken (ships with or creates a wrong/broken xpti.dat). Otherwise I'm using the built-in updater.

If this is a nightly-only problem then we could ignore it. But what if it happens to anyone updating from 2.0 to 2.1, to people like me, who don't use the installer and don't install on top but carefully remove old stuff first? What if this happens when you just update using AUS?

I guess the world would be a better place after a fix for bug 254899.

Comment 4

[Robert Kaiser]

(In reply to comment #3)
> (In reply to comment #2)
> > I don't know how we can do anything more there.
> 
> Well, maybe we could try to find out what is supposed to be in that empty
> dialog and why it is empty (and non-functional, the buttons do nothing)...

That would be good, yes.

> > Both are autogenerated files though, and all we can do is remove them on
> > update/install as we do now.
> 
> The fix in Bug 562047 seems to be for the installer only. I'm not using the
> installer.

removed-files is used by both installer and updater.


> > If you do manual builds and copy one over the other, we can't help.
> 
> I didn't copy one over the other (why would I?). I'm only using ZIP files and
> the internal update (AUS). When using ZIP files, I first remove *all* files in
> the application directory, then extract the archive. I'm only doing that when I
> cannot update the nightly anymore (e.g. because it crashes at startup).
> Obviously in that case the problem cannot appear unless the nightly itself is
> broken (ships with or creates a wrong/broken xpti.dat). Otherwise I'm using the
> built-in updater.

Then you can't have a left-over old xpti.dat, I'd think.

Comment 5

[therube]

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a6pre) Gecko/20100618 SeaMonkey/2.1a2pre

	therube	anyone having troubles with Profile Manager after today's Trunk update? i.e. Profile Manager opens, but is blank?
	therube	found it, Bug 568706 - Empty dialog opened by Profile Manager with old xpti.dat
	therube	note that you can manually enter a Profile name & it will open. so, 'seamonkey.exe -P 20.dumy' will successfully load 20.dumy
	therube	actually maybe that is /similar/ but not exactly the same as what I'm seeing?
	therube	same results in -safe-mode
	therube	Picture: http://i45.tinypic.com/4kxngx.jpg
	therube	i had been updating quite regularly. each update was the small incremental update. today's update was a full ~13 MB.
	therube	running (newly) Windows 7. profiles.ini located here: E:\Users\RUBEN\AppData\Roaming\Mozilla\SeaMonkey\profiles.ini
	therube	OK, noting that in application /components/ xpti.dat & compreg.dat are dated 6-6-2010, nsAddonRepository.js dated 6-8-2010, remainder dated today.
	therube	and rename those three files to *.X & now Profile Manager again shows my Profiles :-).
	therube	& looking at the files individually, it looks to (again) be compreg.dat causing the problem.
	therube	diff between old & new compreg.dat: http://therube.pastebin.com/6tKJxHTn

Comment 6

[therube]

Today's /incremental/ update proceeded without incident.

Only the following files were changed in /components/ directory:
* components.list
* jsd3250.dll
* mail.xptns
* SessionStore.jssuite.dll

Comment 7

[Jens Hatlak (:InvisibleSmiley)]

I got this again when updating from an older nightly to yesterday's and today's, and this time removing xpti.dat wasn't enough, I (also?) had to remove compreg.dat. Adjusting summary. This is starting to suck. :-(

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

Hmm, if I understand Bug 570488 correctly, xpti.dat is gone for good. Might still be relevant for upgrade-from-before-that cases.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to comment #8)
> Hmm, if I understand Bug 570488 correctly, xpti.dat is gone for good. Might
> still be relevant for upgrade-from-before-that cases.

indeed. and should be closeable per bug 525154 comment 14.

Comment 10

[Philip Chee]

> indeed. and should be closeable per bug 525154 comment 14.
Done! Thanks Wayne.