22330 - New app or package reg nodes won't appear until after Comm 4.x is relaunched.

Status: VERIFIED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect, P3)

Description

[David Epstein]

build 1999122023-M12. linux only. works fine if 4.7 isn't running until step 7.
1. Launch 4.7 and use RegToy to check latest Communicator node under "Netscape".
Say it's simply "Communicator".
2. Create new subdir for new Mozilla install.
3. copy Mozilla build to this subdir.
4. From the install subdir, gzip and tar.
5. Run Mozilla (./mozilla).
6. At this point, new node isn't being created in the registry. In Mozilla,
trigger an install script from http://jimbob/trigger2.html. OK.
7. Quit Mozilla and use RegToy again.
Result: "Communicator #2" node isn't created in registry. It will only appear
after quitting and relaunching 4.7.
Expected: #2 Node and key created before quit and relaunch.

Comment 1

[Cathleen]

reassign to dveditz

Comment 2

[Cathleen]

we have a new version registry now.  this is not an issue anymore.
bug meeting 3/20

Comment 3

[Jimmy Lee]

Reassigning QA Contact to David.

Comment 4

[David Epstein]

reg node gets created without having to quit and relaunch.

Comment 5

[David Epstein]

This is still happening with mozver.dat. The new application node doesn't 
display until after quitting/relaunching 4.7 and running BiggerRegToy. Same with 
package nodes (after quit/relaunch of Mozilla, I triggered some xpis. It's a 
refresh problem on linux build.

Comment 6

[Cathleen]

this is very strange.
why do we have a hold of 4.x registry if we are not even writing anything to it?

Dave says this is a linux only problem.

Comment 7

[Cathleen]

Dave, can you verify?

Comment 8

[Daniel Veditz [:dveditz]]

The profile code opens the old registry, but last I checked it did close it 
again. There have been miscellaneous mozregistry.dat closing problems due to 
periodic double-inclusion of the libreg static library by mistake (it's 
happened twice that I know of) so maybe this bug comes from one of those 
periods. 

If that's the cause it 1) would explain why this is Linux only, and 2) be fixed 
now.

Comment 9

[Daniel Veditz [:dveditz]]

I'm assuming this is a result of the double-lib-on-Linux problem that I fixed 
around that time. Hellish to debug since there were subtle interactions between 
two copies of a supposedly singleton global structure, so I want credit for 
fixing this if that's indeed the problem :-)

Comment 10

[David Epstein]

This is fixed for an existing mozver.dat. I installed new mozilla, and it 
created a new mozilla mode w/o having to quit 4.7. But if we start with a new 
mozver.dat, then the problem still remains.

Comment 11

[David Epstein]

will verify this bug and submit another one for the more limited problem 
described above.