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)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
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.
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?
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.
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 (:
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.
(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.
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?
(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?
(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
(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).
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
(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
> 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).
Product: Browser → Seamonkey
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
No specific bug / patch referenced as the fix.

-> WORKSFORME.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
(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.