296611 - post-installation first browser window instance has chrome/XUL problems

Status: RESOLVED DUPLICATE of bug 256496

(SeaMonkey :: General, defect)

Description

[Eyal Rozenberg]

For months now (maybe years) whenever I install a new nightly over an old 
nightly (I think this also happened to me with 1.8 alpha releases), after the 
installation mozilla brings up a browser window, and its chrome is all broken - 
menu item text is missing and a XUL error:

   <broadcaster id="Communicator:Workmode"
---^

(screenshot forthcoming)

Notes:
- When I close it and restart mozilla, everything works fine.
- This also happens if I install the same version again over itself.
- If I remove my profile's chrome dir, post-installation browser looks fine.


may be related to: bug 286252 and bug 191514.

Comment 1

[Eyal Rozenberg]

Attachment: screenshot of problematic browser window

Comment 2

[Eyal Rozenberg]

Somehow, the culprit may be the BiDi Mail UI extension:

http://bidiui.mozdev.org/mail/

that is, using a fresh chrome folder, installing bidi mail ui, then 
reinstalling mozilla triggers this bug. And this is quite strange, since the 
extension in no way overlays the browser window, plus, upon restarting mozilla 
everything works fine, which suggests the extension in itself may not really be 
at fault.

Comment 3

[Darryl Miles]

I get this with SeaMonkey 1.0 (build from source).

When I first installed SeaMoney 1.0b I migrated my profile from Mozilla 1.8a to SeaMonkey 1.0b, I have just built my own version of SeaMonkey 1.0 (hoping to provide feedback about some intermittant problems I experience) however if I run the ./dist/bin/seamonkey resulting file and select my "default" profile.  I see exactly this problem at the bottom.

I also don't get the "File" and "Edit" menu bar icons, just two tiny (5px x 3px) regtangular hot spots where the menus would be.

So I'm back to 1.0b for a bit.  I don't have either of these problems with 1.0b using the same profile.

Comment 4

[Eyal Rozenberg]

Oh, I get with every other install... Mozilla's profile/chrome/whatever parsing is incredibly flakey.

Comment 5

[Darryl Miles]

$ grep -i WorkMode chrome/*
Binary file chrome/comm.jar matches
Binary file chrome/messenger.jar matches

These are files from the newly built SeaMonkey 1.0 dist/bin directory.


A grep of $HOME/.mozilla/**/* does not find anything, so the supposid error is in the clean distribution files (not my profile data).  But if I select a different profile I already have setup there is no problem.

Comment 6

[Darryl Miles]

This problem still persists for me with SeaMonkey 1.0.2.  I have reverted back to 1.0beta unable to upgrade.  1.0 and 1.0.1 also had this problem, so a change between 1.0b and 1.0 must be the cause ?

I have built SEAMONKEY_1_0_2_RELEASE from CVS.

Maybe someone can point me in a direction of how I can help you isolate the problem.

One through I have had if I build SEAMONKEY_1_0b_RELEASE and SEAMONKEY_1_0_RELEASE and confirm the problem then narrow the patch dates to isolate the change that caused this problem.  Is this an effective approach, my concern is that the overall source tree integrity may not be good enough to use that approach ?

Comment 7

[Eyal Rozenberg]

(In reply to comment #6)
> so a change between 1.0b and 1.0 must be the cause ?

No, the problem has existed for several years, it just doesn't consistently manifest, that's all.

Comment 8

[Darryl Miles]

Maybe this will help someone else, from my "default" profile in the "chrome" directory I removed the colorzilla.jar and checky.jar files.  To force SeaMonkey to re-create an chrome policy in my problematic "default" profile I also deleted overlays.rdf and chrome.rdf as well.

Then I re-ordered my broken chrome/chrome.rdf so I could run a diff between the one which does not work and the current default which works (both using modern skin).  I have attached a diff.

Maybe people experienceing this problem can use this to help correct their situation.

Comment 9

[Darryl Miles]

Attachment: chrome/chrome.rdf diff file

chrome/chrome.rdf diff file.  Might help someone else upgrade through this problem.

Comment 10

[Eyal Rozenberg]

(In reply to comment #9)

You're right that this might help, but the thing is, seamonkey is in the process of toolkitizing, and after that happens the profile directory will behave like in firefox and thunderbird. Which is why for the mean time I don't expect that we can interest someone enough to have a closer look at the code. And I don't have the time nor the familiarity with the profile management code.

Comment 11

[Darryl Miles]

<RDF:Description RDF:about="urn:mozilla:package:global-region">
    <c:selectedLocale RDF:resource="urn:mozilla:locale:US:global-region"/>
</RDF:Description>

Thats the problem for me.  If this is missing from the chrome.rdf I get the error.

Comment 12

[Peter Weilbacher]

The basic problem (a broken existing installation) is the same as in Bug 256496, so the same comment applies.

Comment 13

[Darryl Miles]

FYI I have no extensions installed.  I go have Linux binary plug-ins such as, AdobeReader, MozPlugger, Flash, RealPlayer (as well as Demo and Print that come with Mozilla).


Where is the tool to check and fix a "broken existing installation" ?  If an installation can be broken then it needs a tool to check and fix it.