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.
reassign to dveditz
Summary: [PP]After Moz install, new Comm reg node won't appear until after Comm 4.x is relaunched. → After Moz install, new Comm reg node won't appear until after Comm 4.x is relaunched.
we have a new version registry now. this is not an issue anymore. bug meeting 3/20
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID
Reassigning QA Contact to David.
QA Contact: jimmylee → depstein
reg node gets created without having to quit and relaunch.
Status: RESOLVED → VERIFIED
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.
Severity: normal → minor
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
Summary: After Moz install, new Comm reg node won't appear until after Comm 4.x is relaunched. → New app or package reg nodes won't appear until after Comm 4.x is relaunched.
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.
Target Milestone: M16 → M18
Dave, can you verify?
Assignee: dveditz → depstein
Status: REOPENED → NEW
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.
Assignee: depstein → 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 :-)
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
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.
will verify this bug and submit another one for the more limited problem described above.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.