Closed
Bug 237991
Opened 20 years ago
Closed 20 years ago
Browser hangs with Multizilla profile - Multizilla wont install on new profile
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: jgc_nospam, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316 I have just upgraded from 1.6 to 1.7b. When the update program was finished, I got the usual "select profile" box (appears first time after an upgrade) - but when I selected my default profile, nothing happened; the browser just stopped executing with the splash screen and nothing else showing. A second try gave the same result. Then I installed again, this time opening a new profile. This went fine. I went on to install my favourite extensions. One of these failed to install - namely Multizilla (<http://multizilla.mozdev.org>). I get the following error: Chrome registration failed: CHROME_REGISTRY_ERROR -239 This might primarily be a Multizilla problem, but since the problem prevents Mozilla from running if you update from an existing Mozilla/Multizilla installation, I think the Mozilla developers should at least be informed about it. Reproducible: Always Steps to Reproduce: 1. Install Mozilla 1.6 2. Install Multizilla 3. Install Mozilla 1.7 (problem occurs first time) 4: Uninstall Mozilla 5: Reinstall Mozilla (problem remains) Actual Results: Mozilla wont start with the default profile. Another profile (without Multizilla) starts fine. I can stop mozilla.exe using task manager or by logging out of Windows. If I try to restart Mozilla after a new login, the Quality Feedback Agent appears, but as soon as the report is ready to send, the program freezes again. Regarding my choice of severity: I think it is a major problem when the browser wont start. However, I guess that only existing users of Multizilla will experience the problem. I am not a trained bug reporter, so do change the formal settings if you find it appropiate. Finally - I noticed that one of the new features in 1.7 is a blocking mechanism to prevent removal of the content menu. This was allready a feature of Multizilla - so perhaps there is a conflict between the two systems here.
Comment 1•20 years ago
|
||
Sounds like multizilla is not dealing with the registry changes.... In general, I suspect that most extensions need to be updated to actually work with 1.7. But we shouldn't be hanging, should we?
Comment 2•20 years ago
|
||
It's probably a systemic problem that's hard to fix, but I could use QA with a debug build (report any interesting debug spew). Is multizilla installing itself to the profile or the application directory? Does it install components, or is it chrome-only?
(In reply to comment #2) > It's probably a systemic problem that's hard to fix, but I could use QA with a > debug build (report any interesting debug spew). > > Is multizilla installing itself to the profile or the application directory? Up to the user. Both can be selected at first install. > Does it install components, or is it chrome-only? We've got two components and a bunch of chrome stuff. Note that I was away to Spain for several weeks and only returned yesterday, so I completely missed all recent changes. Note that using a new profile seems to work, no errors in install.log, but it somehow forgets to add the overlay info in chrome/overlayinfo/xxx/overlays.rdf
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #1) > Sounds like multizilla is not dealing with the registry changes.... What changes? > In general, I suspect that most extensions need to be updated to actually work > with 1.7. But we shouldn't be hanging, should we? Is there any info about this?
hmm, i didnt have this problem but then multizilla here was installed in the profile not the mozilla dir.
This is a serious issue. I'm getting a lot of complains. Benjamin, do you have any pointer about the chrome registry changes for me?
Severity: major → critical
oops, disregard my old post. i mixed up what version of multizilla it affected. i got the chrome registry error now when trying to install 1.6.3.0c on mozilla 1.7beta.
Comment 8•20 years ago
|
||
There were not any major chrome registry changes in this timeframe. I would like to see hard data such as crash stacktraces.
(In reply to comment #8) > There were not any major chrome registry changes in this timeframe. Oh, but what about comment #4? >I would like to see hard data such as crash stacktraces. I don't have a debug build, nor am I allowed to send crash data from our network, silly but true (:
Comment 10•20 years ago
|
||
I moved the loading of userChrome/userContent and style overlays from the chrome registry to content. Given the symptoms so far, however, I doubt that is the direct cause of the problems (it might have an indirect relationship, because I changed the nsIChromeRegistry IID or something similar). Without further debugging data, I'm not going to spend energy on this bug. If you can show me that the chrome registry is at fault, and not multizilla, I'll be happy to look at this bug again. The systemic problem I mentioned is that we don't (yet) have a way of disabling profile-installed extensions, so crashes upgrading versions is very likely and not really preventable.
Comment 11•20 years ago
|
||
(In reply to comment #10) > I moved the loading of userChrome/userContent and style overlays from the chrome > registry to content. Given the symptoms so far, however, I doubt that is the > direct cause of the problems (it might have an indirect relationship, because I > changed the nsIChromeRegistry IID or something similar). Without further > debugging data, I'm not going to spend energy on this bug. If you can show me > that the chrome registry is at fault, and not multizilla, I'll be happy to look >at this bug again. Well, I didn't change anything in install.js nor contents.rdf and MultiZilla worked for three years, without any problems, so please explain to me what it is that I do wrong. We've never had this kind of troubles before! Mozilla installs MultiZilla, and other add-ons, without errors, with a new profile, but the XPInstall process forgets to add important lines to chrome.rdf so this must be a mozilla bug.
Comment 12•20 years ago
|
||
Oops. I checked the md5 and we missed a bit. The current version of MultiZilla (1630D) can now be installed without any problems, at least chrome.rdf is complete and MultiZilla works like before. Jens, Kenneth, can you guys please confirm this, so that we can close this bug?
Comment 13•20 years ago
|
||
(In reply to comment #10) > The systemic problem I mentioned is that we don't (yet) have a way of disabling > profile-installed extensions, so crashes upgrading versions is very likely and > not really preventable. It there a bug filed for this issue and if so what is the bug number?
Reporter | ||
Comment 14•20 years ago
|
||
(In reply to comment #12) > Oops. I checked the md5 and we missed a bit. The current version of MultiZilla > (1630D) can now be installed without any problems, I can only find version 1.6.3.0 C on Multizillas web site - and it won't install on my 1.6 (haven't updated this machine yet). The error is the same as the one I get with 1.7B (in a new profile) - i.e. "Chrome registration failed". /Jens
Comment 15•20 years ago
|
||
(In reply to comment #14) > I can only find version 1.6.3.0 C on MultiZillas web site - and it won't install > on my 1.6 (haven't updated this machine yet). The error is the same as the one I > get with 1.7B (in a new profile) - i.e. "Chrome registration failed". Prior versions of MultiZilla can be found from the installation page, simply look for "Prior Versions" right under the menu. Also, mozdev.org works with download mirrors and these mirrors need time to update, that is why it might take several hours before you actually see a new update i.e. that is why we update head.txt (PHP version info) a bit later. The only problem left now is that element.builder.rebuild(); crash, when you hover over menu item Browser Spoofing (QPrefsMenu).
Reporter | ||
Comment 16•20 years ago
|
||
Sigh - now I've upgraded from 1.7B to 1.7RC1, and found myself having the exact same problem once again. This is frustrating /Jens
Comment 17•20 years ago
|
||
(In reply to comment #16) > This is frustrating Same CHROME_REGISTRY_ERROR? Btw, did you install MultiZilla in your profile directory? See also: http://mozillazine.org/talkback.html?article=4650#19 and follow ups
Reporter | ||
Comment 18•20 years ago
|
||
> Same CHROME_REGISTRY_ERROR? No - I forgot that my original bug report mentioned both a problem with launching Mozilla after an upgrade and a problem with installing Multizilla in a new profile. This time there were no problems installing the nightly build of Multizilla in a new profile - but the problem with using an existing profile remains. The profile that made Mozilla freeze after the update had the latest nightly build of Multizilla installed. I am up and running again - using the following procedure: 1) Make a clean install (deleted all files in the program directory, but not the profile files) (after this step, the Mozilla still froze when I tried to launch it with my standard profile. Using the job list to kill mozilla.exe it was possible to start with another profile) 2) Start Mozilla with an existing profile with no extensions installed 3) Install a couple of extensions that have previously caused upgrade problems (launchy and multizilla) - I am not sure whether this step actually influenced the final solution, but this was what I tried to do). 4) Delete the normal profile - files included 5) Use Mozilla Backup to recreate the profile (I took a backup of the profile just before updating - with good reason, appearantly) > Btw, did you install MultiZilla in your profile directory? I can't remember - sorry. I can check it if you tell me how (and it still is important).
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 19•20 years ago
|
||
This is no longer a problem. I'm resolving it as FIXED, either in MultiZilla or in Mozilla but I think the latter because we didn't change a bit!
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 20•20 years ago
|
||
No specific bug / patch referenced as the fix. -> WORKSFORME.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•20 years ago
|
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
Comment 21•20 years ago
|
||
(In reply to comment #20) > No specific bug / patch referenced as the fix. > > -> WORKSFORME. I don't have a specific bug number, but there WAS a bug fixed for another add-on presumably linky, so this IS fixed in Mozilla!
You need to log in
before you can comment on or make changes to this bug.
Description
•