Closed Bug 130331 (key_irc) Opened 22 years ago Closed 22 years ago

red error code text displayed under status bar ("key_irc")

Categories

(Core :: XUL, defect, P1)

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla1.2beta

People

(Reporter: emanu_mary, Assigned: jbetak)

References

Details

(Keywords: helpwanted, relnote, Whiteboard: [adt3] have patch / need r=/sr=/a=)

Attachments

(3 files, 1 obsolete file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310
BuildID:    20020310

 i sent an attachment with a screenshot of the frontend of my 0.9.9 build of
mozilla. I tried to change some options in Preferences but i was not able to
change the interface. Is it a bug?

Reproducible: Always
Steps to Reproduce:
1.open Mozilla
2.
3.

Actual Results:  Strange frontend
Additional information:
in the screenshot the personal toolbar was hidden by me; 
installing mozilla without chatzilla delete one of the two red lines at the
bottom, installing it without debugger too solve the problem.
I can surf the web normally even with that front-end.

Kernel 2.4.18
Mandrake 8.1 
resembles bug 127044
To rginda.  It looks like debugger/chatzilla is not installing locale stuff
correctly...
Assignee: trudelle → rginda
*** Bug 130349 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
bz, do you have something specific in mind when you say, "debugger/chatzilla is
not installing locale stuff correctly"?

This hasn't been a problem in the past, and nothing locale related in chazilla
or the debugger has changed in a *very* long time.

I suspect this is a regression elsewhere, but I don't even know where to start
looking.
bz, please see my last comment
Robert, my first guess was that the locale files are not being properly packaged
in installer builds...  If you haven't changed any of that stuff recently, I'm
really not sure where the problem would be.  :(
From the screenshot, it looks similiar to the problem described at
http://slashdot.org/comments.pl?sid=29319&cid=3146725.
Emanuele, how did you install Mozilla?
Blocks: 130484
I installed the "x86 Talkback enabled Full Installer"
and downloaded it with Prozilla. I used the same metod with 0.9.7 and 0.9.8 but
i have never had similar problems.
*** Bug 130574 has been marked as a duplicate of this bug. ***
Again: I don't think this has to do with chatzilla.
Bug 127044 show similar screenshots.
Ok.  Since people are seeing this with things other than chatzilla...
Assignee: rginda → trudelle
Severity: normal → major
No longer blocks: 130484
*** Bug 130484 has been marked as a duplicate of this bug. ***
->Installer, per previous comments.
Assignee: trudelle → dveditz
Component: XP Apps → Installer
QA Contact: paw → bugzilla
please try one of or all of the following:
1. install mozilla into another directory. Dont install "ontop" of another
installation
2. try creating a new profile

I'm pretty sure this bug is not installer.

At least it's not win32 so I'm out of here....:)
QA Contact: bugzilla → ktrina
I'm seeing this in nightly 20020314 on win95 installed from the zip file.
Unzipped into a new directory, new profile.
also see new bug 131016
Back to XP Apps, it also happens to at least some people when they unzip, no 
installer involved.
Assignee: dveditz → trudelle
Component: Installer → XP Apps
QA Contact: ktrina → paw
People have reported this to me that have dom-inspector or the js-debugger
packages installed and use a non-US locale.  Does that help?
Yes, that is a big clue. When a package doesn't have a specified locale or skin 
I thought the chrome registry was supposed to fall back to the default, or 
perhaps whatever happened to be registered first. If that's not happening and 
we're trying to use a non-existant locale it might be causing these symptoms.
OS: Linux → All
->hewitt
Assignee: trudelle → hewitt
Component: XP Apps → XP Toolkit/Widgets: XUL
--> qa shrir@netscape.com
QA Contact: paw → shrir
Keywords: nsbeta1
I download and installed win32 zip files today. They both show 2002031503 as the
build. The latest file is time stamped 12:09 and is 300k larger than the one
time stamped 07:45.  The later one does *not* work, and the earlier one does.
The one that does *not* work includes the embed.jar file, while that file is not
in the zip that does work. Hope this helps...
The "bad" one has embed.jar listed in installed-chrome.txt
Looks like an automated build/packaging problem. Removing the embed.jar and
associated lines from installed-chrome.txt makes that download work. See bug 131016.
*** Bug 131958 has been marked as a duplicate of this bug. ***
*** Bug 132029 has been marked as a duplicate of this bug. ***
I have seen this problem with build 2002031803 on Win98SE. I've used the 
talkback enabled zip file. Removing all the lines containing embed.jar from 
installed-chrome.txt solved the problem for me.
Emanuele: Do you still see this problem on an install of 0.9.9 using the same
process? If so, could you please do the following and see if it works:

Delete the file embed.jar from your mozilla\bin\chrome directory
Open installed-chrome.txt (in the same directory) and delete every line that
contains embed.jar

If this solves your problem, then this bug is the same as bug 131016

If embed.jar is getting installed, apparently the UI barfs. The screenshot
attached is almost exactly what people are experiencing in bug 131016, and if
these are dups it would make everyone's lives so much easier.

If this does not solve your problem (either there is no embed.jar, or deleting
it does nothing) Then this is indeed a seperate bug and all issues with the
nightlies should be addressed in bug 131016
Keywords: mozilla1.0
well, i reinstalled mozilla completely but i didn't find any embed.jar file; so
i reinstalled it without debugger and chatzilla, even in this case i could not
find embed.jar.
My front-end is slightly different, see at
http://bugzilla.mozilla.org/attachment.cgi?id=74978&action=view

My build (2002031104) does not contain embed.jar, I installed bad (changing the
old version directory name -without really uninstalling it- and installing the
new version in the directory of the precedent installation), I tried to
reinstall it but I think some of the older the version is still here.
Anyhow somebody knows where does the writes I see come out? I thought they came
from some configuration file but I didn't find them in a readable file.
*** Bug 132560 has been marked as a duplicate of this bug. ***
I installed a new profile, all right. Now some expert on mozilla profiles could
help me
I resolved the bug on my system.
I created a new profile, then i took the chrome.rdf file founded in {new profile
directory}/chrome and I copied it over the chrome.rdf file of the old profile.
I'm puzzled that some people say this is a problem in a new profile, yet
Gabriele fixed an old profile by copying a file from a new profile.  qawanted,
shrir- could you please try this and comment?
Keywords: qawanted
I've had people report this to me with old profiles as well.
I tried the same moz builds/installs (linux and windows) that reporters of this 
and all duped bugs have mentioned. However, I was unsuccessful in reproducing 
this problem. Have sent  an email to the reporters to check this out on a very 
recent build and see if it helps. for me, it's a WFM.
forgot to mention, also tried old,new profiles as well, but to no avail.
nsbeta1- per Nav triage team. helpwanted
Keywords: nsbeta1helpwanted, nsbeta1-
The same with RC1. I could solve only not installing debugger and chatzilla
*** Bug 138510 has been marked as a duplicate of this bug. ***
*** Bug 138843 has been marked as a duplicate of this bug. ***
*** Bug 138510 has been marked as a duplicate of this bug. ***
so this is a chrome registry problem, right?

people have listed possible culprits such as localizations and dangling
references to embed.jar. did i miss anything?

My current relnote thoughts:
If you see red xml text in the browser window then you should install a new
mozilla in a new directory and create a new profile.  If you need to salvage
your old profile you might be able to do so by copying chrome.rdf from your new
profile to your old profile.
Keywords: relnote
*** Bug 142595 has been marked as a duplicate of this bug. ***
*** Bug 143478 has been marked as a duplicate of this bug. ***
*** Bug 143002 has been marked as a duplicate of this bug. ***
*** Bug 144038 has been marked as a duplicate of this bug. ***
*** Bug 145232 has been marked as a duplicate of this bug. ***
*** Bug 147149 has been marked as a duplicate of this bug. ***
*** Bug 147140 has been marked as a duplicate of this bug. ***
*** Bug 147219 has been marked as a duplicate of this bug. ***
*** Bug 147233 has been marked as a duplicate of this bug. ***
*** Bug 147769 has been marked as a duplicate of this bug. ***
*** Bug 151175 has been marked as a duplicate of this bug. ***
*** Bug 151356 has been marked as a duplicate of this bug. ***
*** Bug 151953 has been marked as a duplicate of this bug. ***
*** Bug 153328 has been marked as a duplicate of this bug. ***
*** Bug 154510 has been marked as a duplicate of this bug. ***
*** Bug 154553 has been marked as a duplicate of this bug. ***
*** Bug 154527 has been marked as a duplicate of this bug. ***
*** Bug 155572 has been marked as a duplicate of this bug. ***
i had the same problem (Build 2002053012 W9x, red text "<key id=key_irc"
key=&ircCmd.commandkey;"
command="Taks:IRC" modifiers="accel"/> --^ " appeared ). i created a new profile
and the chatzilla-icon appeared again and the red text disappeared. then i
updated another computer that accesses the same new profile to v1.0. the red
text appeared again. than i updated the german language pack on this computer
and the red text disappeared. 
This thread claims to know the root cause for this problem, I havn't looked into
it though...

<http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF8&selm=3D25F153.6080603%40aol.com>
*** Bug 158817 has been marked as a duplicate of this bug. ***
Alias: key_irc
Summary: Strange front-end in 0.9.9 → Strange front-end in 0.9.9 ("key_irc")
i have the same till version 1.1alpha,

prior i installed netscape 7pr1

can the install of ns 7pr1 the reason for this prob?
ns7pr1 and mozilla share the same user-profile-directory

i deleted the whole profile directory, and started mozilla he asks to create a
new one

this fixed the prob for me!
*** Bug 144328 has been marked as a duplicate of this bug. ***
*** Bug 159491 has been marked as a duplicate of this bug. ***
*** Bug 159517 has been marked as a duplicate of this bug. ***
I have the same problem with 1.1 Beta on two different PC's (both Win98 SE)
I just installet the beta over the alpha. After deinstalling and new
installation still the same.

If I greate a new Profile it works fine with the new one.

I am not a programmer, but perhaps this can help: The path to the profiles is
(because of an german windows) windows/anwendungsdaten/mozilla... I had also
some weeks ago a german language pack installed togetter Mozilla 1.0.
Could it be, that the german word "anwendungsdaten" in the path makes trouble by
new installations?
 
I had the problem on my computer (Mozilla 1.1b on Mac OS X), and I did the
following to get rid of it:

* Quit Mozilla 1.1b
* Launch Mozilla 1.0
* Go to Preferences/Appearance/Languages&Content
* De-select both German localisation packages and select the US pacakges
* Quit Mozilla 1.0
* Launch Mozilla 1.1b

The red line of text was gone then, and the front end looked perfectly okay; the
ChatZilla icon had returned as well.

Apparently it has to do with still partly active language/content packs that
don't migrate well to a new version. To get rid of it, you have to go back to
the version under which you installed the language pack, de-activate it, and the
n launch the new version.
The way to solve the problem from #74 was not working on my system (Win98SE) -
still the same problem.
The only way what was working in my case was to set up a new profile. 
renominate for nsbeta1 in 1.2 cycle. Time to stop being 'fragile'.
Keywords: nsbeta1-mozilla1.2, nsbeta1
*** Bug 161544 has been marked as a duplicate of this bug. ***
*** Bug 161653 has been marked as a duplicate of this bug. ***
*** Bug 158814 has been marked as a duplicate of this bug. ***
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt3]
*** Bug 163600 has been marked as a duplicate of this bug. ***
rginda:
I believe this could be solved if chatzilla would have some localeVersion set in
contents.rdf (this should be the same as in the rest of Mozilla, of course).

It looks as the chrome registry can't deal very well with components having no
localeVersion, as it's the case for chatzilla currently.
You probably should also add a skinVersion at the same time.
That may be the case, and I'll be happy to fix it, but we shouldn't f(l)ail like
this just because of a missing version.  Someone should really take a look at
the root problem here.
*** Bug 163600 has been marked as a duplicate of this bug. ***
*** Bug 163999 has been marked as a duplicate of this bug. ***
*** Bug 164775 has been marked as a duplicate of this bug. ***
*** Bug 164770 has been marked as a duplicate of this bug. ***
ccing tao, per comment 82.  Who else would know about this localeVersion stuff?
*** Bug 164831 has been marked as a duplicate of this bug. ***
bz: perhaps the people who originally implemented that localeVersion stuff? (not
sure who did that though...)
*** Bug 164922 has been marked as a duplicate of this bug. ***
*** Bug 165125 has been marked as a duplicate of this bug. ***
*** Bug 165341 has been marked as a duplicate of this bug. ***
*** Bug 165415 has been marked as a duplicate of this bug. ***
*** Bug 165527 has been marked as a duplicate of this bug. ***
*** Bug 165675 has been marked as a duplicate of this bug. ***
*** Bug 165675 has been marked as a duplicate of this bug. ***
*** Bug 165773 has been marked as a duplicate of this bug. ***
*** Bug 165913 has been marked as a duplicate of this bug. ***
This is for the 1.0.1 branch, it will have to be updated for the tip.
I've been playing with this on and off for a lot of the day and the problem
causing this bug seems to be pretty simple: most translations are missing
translation bits for chatzilla.

I think that this is because most translations are generated from en-US.jar and
chatzilla, venkman and the DOM inspector all ship the locale for their specific
applications as part of the various .jar files.  This means that the translators
are missing them.

When the locales are loaded, if the ircCmd.key key is missing from the
translation, then you get the error that everyone is seeing.  That's what is
actually causing the error.

I think that it's curious that in the chrome.rdf file that's generated in my
home directory when I switch languages, the chatzilla locale url actually is for
the language that I picked, even though there is no locale for that language
with chatzilla.  Is this a problem with the chrome registry?  I would expect it
to fall back to the default that I have selected, en-US, which does exist.

Anyway, the version information should probably be set for chatzilla, which is
what the previous patch does.  It doesn't actually fix the problem but it's the
right thing to have in the tree.
Oh.  So far the only l10n I've seen that fixes this is the zh-CN translation for
1.0.1.
*** Bug 166058 has been marked as a duplicate of this bug. ***
Comment on attachment 97418 [details] [diff] [review]
patch that adds localeVersion to chatzilla

Why 1.0.1rc1 for the locale, and 1.0 for the skin?  Will 1.0.1rc1 have to be
changed to 1.0.1 when 1.0.1 is shipped?
They are different things, iirc.  1.0.1 is going to ship with 1.0.1rc1.  Blame
the build team. :)
Comment on attachment 97418 [details] [diff] [review]
patch that adds localeVersion to chatzilla

r=rginda
Attachment #97418 - Flags: review+
hehe, hi all, just my 2 cents: 
i had this problem again, and i removed the following lines from crome.rdf under
my default profile (i didn't have to erase all my mail-server settings and stuff)
and the error lines are completely gone for now!!! 
i truly think, this is a localisation problem.

balint

  <RDF:Description about="urn:mozilla:package:venkman">
    <c:selectedLocale resource="urn:mozilla:locale:hu-HU:venkman"/>
    <c:selectedSkin resource="urn:mozilla:skin:modern/1.0:venkman"/>
  </RDF:Description>
  <RDF:Description about="urn:mozilla:package:chatzilla">
    <c:selectedLocale resource="urn:mozilla:locale:hu-HU:chatzilla"/>
    <c:selectedSkin resource="urn:mozilla:skin:modern/1.0:chatzilla"/>
  </RDF:Description>
After installing V1.1 directly over 1.1beta (with German locale) i ran into this
problem. Deleting all de_*.jar-Files in the chrome directory solved the problem.
If you change your chrome.rdf to this:

   <RDF:Description about="urn:mozilla:package:chatzilla">
     <c:selectedLocale resource="urn:mozilla:locale:en-US:chatzilla"/>
     <c:selectedSkin resource="urn:mozilla:skin:modern/1.0:chatzilla"/>
   </RDF:Description>

it should work as well.  It's a shame that the chrome registry is writing files
that include packages that don't exist. :(
*** Bug 166532 has been marked as a duplicate of this bug. ***
*** Bug 166537 has been marked as a duplicate of this bug. ***
*** Bug 166237 has been marked as a duplicate of this bug. ***
Hallo to all,

This is what solved the „Red error code“ problem for me :-).

I was using the German language (de-AT) version 1.1 final, which I unpacked from
the talkback.zip-file from http://www.mozilla.kairo.at – running into this
problem for the first time. My OS is Windows XP.

I simply did the following:

- I deleted the folder which I unpacked the talkback.zip-file to
- I deleted one registry entry using RegCleaner (www.jv16.org) – but I think
this is only from the link on the destop, isn't it?
- I downloaded the file mozilla-win32-1.1-deAT-installer.exe from ftp.mozilla.org
- I installed this file into a new directory (named the same as the deleted one
;-)) choosing all components

That's it! The red lines are completely gone for now and I'm able to use
ChatZilla. Don't you think this is a problem with the talkback.zip files? In
what way the installer.exe files are different from those files?
*** Bug 168141 has been marked as a duplicate of this bug. ***
*** Bug 168192 has been marked as a duplicate of this bug. ***
*** Bug 168207 has been marked as a duplicate of this bug. ***
changing summary to (hopefully) make this more findable.
Keywords: mozilla1.0
Summary: Strange front-end in 0.9.9 ("key_irc") → red error code text displayed under status bar ("key_irc")
Some things that should me mentioned:
1. I installed Mozilla 1.2alpha (english) over an installed Mozilla 1.1 (german)
on a german Windows XP. I chose "complete install" in the Mozilla setup program.
Mozilla 1.1 was installed the same way. Result: Red letters on the bottom
talking about "key_irc"
2. Chatzilla was completely missing at this time, neither reachable via menu
item nor via the litte button on bottom left (this button was missing, too)
3. I removed every evidence of Chatzilla in both chrome.rdf files (in user
profile and system), t.i. the complete sections from <RDF to /RDF>. Still the
red problem occured.
4. I removed all german language files I could find. The problem persisted.
5. I replaced all occurences of de-AT with en-US in the .rdf-Files. Didn't help.
6. I reinstalled Mozilla 1.2alpha and chose the "Browser Only" option in setup.
Mozilla worked perfectly then, even chatzilla was back.

Maybe this helps tracking down the problem.
A few days ago I installed the new Mozilla version 1.2a (English language
installer.exe-file, downloaded from ftp.mozilla.org, complete install, BuildID:
2002091014) parallel to the German language 1.1 final (installer.exe-file,
downloaded from ftp.mozilla.org, complete install, BuildID: 20020826) into a
separate directory, and I still don&#8217;t experience the &#8220;red code&#8221; problem despite
of this. My personal bookmarks, mailbox folders etc. are still there and were
&#8220;imported&#8221; into 1.2a and the &#8220;old&#8221; 1.1 final still works fine and in German
language.

There is only one quite strange phenomena: When I open a 1.2a browser window and
later on SIMULTANOUSLY try to open a 1.1 final window via the windows explorer,
the new opened window seems to be a second one of 1.2a (because of the BuildID
shown and the English language front-end). Is this a (new) bug or intented?
I add my experience with this bug too (occured on Mozilla de_AT 1.1a & 1.1)
in the file: MOZ_HOME/chrome/chatzilla.jar:/content/chatzilla/chatzillaOverlay.xul

I comment out these 3 entries:
<key id="key_irc"  key="&ircCmd.commandkey;" command="Tasks:IRC" modifiers="accel"/>


<menuitem
        label="&ircCmd.label;"
        accesskey="&ircCmd.accesskey;"
        key="key_irc"
        command="Tasks:IRC"
        id="tasksMenuIRC"
        class="menuitem-iconic"
        insertbefore="tasksMenuEditor"/>


<toolbarbutton class="taskbutton" id="mini-irc" oncommand="toIRC()"
    position="5" tooltiptext="&ircCmd.label;"/>


with this I get rid off the error text, but also the ChatZilla

These 3 items connect the ChatZilla to Mozilla-GUI (Menu-Item, Accelerator-Key,
Toolbar-Button)
This problem is caused by the XUL.mfl from the profile.
I had this problem several times and solved it by replacing the XUL.mfl from my
profile with a clean one (from a new profile).

Seems like Mozilla makes the XUL.mfl defective, in a situation where a profile
demands a chrome that is not existing or working. I think that because it happends:
When installing a new Mozilla (I always delete the old one first) I guess
chromes are deleted too, but profile demands some.
Like I have different themes installed I use and the Preference tolbar.

Last time I had this problem was  few starts after I installed the new
Preference Toolbar 2.0 (from www.xulplanet.com).

I hope this helps.
*** Bug 169237 has been marked as a duplicate of this bug. ***
I just veriefied it on another machine. 
The reason for such a message is just in the profile. 
And it seems like XUL.mfl carries stuff shat should not be used any more when
the Mozilla files changes (either with a "delete first" update) or a partly
update like pref panel
In the seond case it's only complicated if you have more then one profile.
The XUL.mfl file format records the path and modified times for the jar files
from which the fastload file's contents were created. When the app tries to
use the fastload file it checks this path and modified-time information and 
if it does not match exactly, then the app will destroy the current XUL.mfl
and begin creating a new one.

So, are you saying that this is not happening on your system. I can confirm
that this is working correctly with a current trunk build on win2k, and I 
know that the code that handles this has not changed in some time. (And, if
it is not happening on your system, it's actually a different bug than this
one, which is about a problem with the chrome registry and missing packages, 
etc.).
John:
FastLoad rebuilding does NOT work correctly with .dtd files, it seems. This is
what bug 142623 is all about, and the workaround that is still in place does
fail sometimes (still noone made up a real fix for that issue...)

:(
I'm aware of bug 142623. That's an entirely different issue, no? So don't 
add unrelated comments to this bug.
John:
sorry. I just think that Comment #121 mentioning XUL.mfl is an issue of bug
142623. Sometimes when that one's workaround is failing, my users still see the
"key_irc issue", even though they killed their profile's chrome directory, what
helped in most cases until the 1.0 branch (and bug 142623 was introduced
afterwards).
Killing the FastLoad file doesn't help in the real case of this bug though, the
XML error line is still present (that's why I think this is no FastLoad bug).
What does help in most cases (as said above) is killing the profile's chrome
directory.
*** Bug 169903 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 150180 has been marked as a duplicate of this bug. ***
*** Bug 166484 has been marked as a duplicate of this bug. ***
*** Bug 170307 has been marked as a duplicate of this bug. ***
i was using mozila 1.0 
i wanted to try the new version
since i installed the 1.1b i have two lines in red 
menuitem position....
key id="key_irc"....
i tried to uninstall all mozila version
the bug stay when i reinstall it
i tried uninstall mozilla, delete the mozilla directory, restart the pc
and the next day install the good vresion of mozilla
the bug is still here
i tried phoenix its works well
i don't know...
*** Bug 170926 has been marked as a duplicate of this bug. ***
*** Bug 171039 has been marked as a duplicate of this bug. ***
Over here the same problem after upgrading from version 1.0.

Could it be a problem with Netscape 7.0 - which is also installed here under
Win2000 SP2

Martin
I set up an new profile - and the strange red lines are gone... Seems the the
upgrade from 1.0 to 1.2a forgot to upgrade something in the existing profile -
with the new all thing seems to be OK. 

The only point: All setups in the first profile had to be done again...

Martin
OK, we need to get this fixed for 1.2b.  I think that we need to be falling back
to the default locale, as listed in installed-chrome.txt file.  This is usually
en_US, which is good enough IMHO.

Who can work on it?  It's got _tons_ of dups.
Blocks: 1.2b
hot potato.

so if preferences can report that a locale is unusable, we should also be able
to figure out early enough to systematically try each locale until one works. if
we run out of locales, we give up.

"Alert - &brandshortname;"
Unable to find a locale that supports packages with language version %s.
Please reinstall &brandshortname;. You can contact %s to get an updated %s
language pack.

[Exit]
--
input:
[xulPackageRequiredVersion,
 vendorUrlForProfileLocale,
 prettyProfileLocaleName]
--

Additional Possibilities:
A. we could offer them a textfree browser which just visits mozilla.org's
download page.  It'd be annoying, but not quite unprecedented, when iCab betas
expire they only browse to the download site.
Assignee: hewitt → jbetak
A quck fix:
I had the bug when trying out V1.2a and could not fix it, even going back to 1.0.

However, I finally found a quick fix :
- Choose the custom install
- Uncheck "ChatZilla" and "Debugger"

The annoying error messages are gone.

Yhis worked both with 1.0 and 1.2a

Éric.
The upgrade from RC1 DE-AT to 1.1 DE-AT (deleting all files of RC1 except the
plugin directory and installing 1.1 from the zip file in the previous folder)
gave me the "key_irc" text. As I wanted a quick fix and didn't desperately need
the 1.1 functionality I downgraded to 1.01 DE-AT via the same procedure as
above. This did not remove the red error message. There was a quick solution
though: I installed the EN-US language pack for non-english 1.01, switched the
language to EN-US, re-started Mozilla (the error message was still there) and
switched the language back to DE-AT. It's all fine now.
*** Bug 171988 has been marked as a duplicate of this bug. ***
*** Bug 172133 has been marked as a duplicate of this bug. ***
*** Bug 172492 has been marked as a duplicate of this bug. ***
*** Bug 172471 has been marked as a duplicate of this bug. ***
Problem fixed:
1. Uninstall Mozilla 
2. reboot
3. Install new Mozilla version into other directory
--> all bookmarks and mails are available
Assignee: jbetak → hyatt
And you reassigned this because?
Assignee: hyatt → jbetak
well, I guess Thomas reassigned this to hyatt, because he wisely realized that I
haven't caught up with the fact that as of 09/27 I'm the lucky new owner of this
bug ;-)

I agree with the assertion that this should make it into 1.2. If we decide to go
with the localeVersion patch from blizzard and perhaps some additional
packaging/localization tweaks, the trunk freeze shouldn't affect us. I don't
think I can whip up an acceptable solution today though... 

IMHO hyatt might be the best (and most obvious) owner, if we wanted to change
the chrome registry. That is, if he is available.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.2beta
For now i have un-install an dre-install with-out Bugzilla and chatzilla and all
is ok.

RG
*** Bug 173544 has been marked as a duplicate of this bug. ***
*** Bug 173544 has been marked as a duplicate of this bug. ***
*** Bug 173712 has been marked as a duplicate of this bug. ***
*** Bug 173926 has been marked as a duplicate of this bug. ***
*** Bug 174099 has been marked as a duplicate of this bug. ***
I'm hoping to come up with a last-minute fix for the 1.2 release. Although there
is extensive info available in this bug and in its 1001 duplicates, I'm very
open to any ideas and suggestions :-)

restating repro steps that worked for me:

1) install Moz 1.0
2) create a new profile and select it
3) install and select the French language pack for Mozilla 1.0
4) install Moz 1.1 and try to use the profile created in step 2)

workaround:

1) find your current Mozilla profile
2) delete chrome.rdf
3) delete XUL.mfl

> 3) delete XUL.mfl

The last step is not necessary (despite folklore to the contrary). If the 
paths and timestamps of the '.jar' files for a build do not match the paths
and timestamps stored in the fastload file _exactly_, then the fastload 
code will abort and delete the fastload file (and begin creating a new fastload
file from the current build's contents).
Blocks: 1.2
No longer blocks: 1.2b
John, you're right. A closer look reveals that XUL.mfl gets regenerated when the
profile is accessed by a new Mozilla version for the first time :-)

But what if someone has started using a new Mozilla version with an old profile?
Deleting chrome.rdf will not be enough to get rid of the annoying XUL error
message. At that point they'll have to zap XUL.mfl as well. At least that's what
I saw on in my test scenario the other day...
I dug up some old bugs to refresh our collective memory. Per Tao's comment in
bug 86807, we are not capable of removing profile-bound chrome registry
references to non-existent chrome providers, which I believe was one of the
requests made in this bug. 

We can achieve the same effect by versioning chrome packages, the required
chrome registry changes were implemented in bug 76512.

http://bugzilla.mozilla.org/show_bug.cgi?id=86807#c52

The most recent patch version seems to prevent the XUL error code from appearing
- in my aforementioned test scenario at least. Looks like this is all we need
for 1.2.

tao, leaf - what do you think? If this goes in, we might need to update leaf's
localeVersion scripts to include chatzilla and venkman.

would anyone care to r= & sr=?
Whiteboard: [adt3] → [adt3] have patch / need r=/sr=/a=
Ok, I see (I think). In step 4 of comment 154, as the browser starts and the 
profile is selected, the current XUL.mfl file _is_ blown away and a new 
serialization is begun. However, it then hits this bug and we actually 
serialize the error (the red markup) into the fastload file as part of the 
XUL serialization. (Note: prior to 1.1 builds we only serialized JS). So, it 
is in fact, as jbetak pointed out, necessary to delete the XUL.mfl file because 
it now contains a bogus serialization, but as far as fastload service is 
concerned it's all OK. My wrong.

That's kinda sucky, but if we can prevent the error from occurring with locale
versioning, then I guess we can live with that.
jbetak:
I didn't test it but the patch looks quite good to me.
It looks cleaner than the first patch which alread had r=rginda in Comment #106

If it is allowed to be counted as such, I dare to say r=kairo@kairo.at
Comment on attachment 103101 [details] [diff] [review]
new patch (mimics blizzard's approach)

sr=alecf
Attachment #103101 - Flags: superreview+
*** Bug 175040 has been marked as a duplicate of this bug. ***
Comment on attachment 103101 [details] [diff] [review]
new patch (mimics blizzard's approach)

r=rginda
Attachment #103101 - Flags: review+
Comment on attachment 103101 [details] [diff] [review]
new patch (mimics blizzard's approach)

a=asa for checkin to 1.2 (on behalf of drivers).
Attachment #103101 - Flags: approval+
arg, about time to put this to bed - thanks everyone!

I filed a follow-up (bug 175140) for the chrome registry fix. The trunk fix will
only kick in, if there is a chrome version change. So someone using two
instances of the same release (one with a language pack and one without) might
still run into this problem. Although that's an unlikely scenario, I believe
that many people (including me) would like to see the chrome registry changes
implemented soon.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 175151 has been marked as a duplicate of this bug. ***
*** Bug 175228 has been marked as a duplicate of this bug. ***
*** Bug 175496 has been marked as a duplicate of this bug. ***
Dear developers,

I am not sure if this is the right place to report this bug abain. I use Mozilla
1.2b, build 2002101612 and still have the problem but as I understand this
reporting the problem should be solved (which isn't.)

cheers - gl
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Dear Gerhard,

As you see from looking at this bug, it was approved for 1.2 (_final_, not
_beta_) and fixed on Oct 17, the day _after_ 1.2beta shipped.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Gerhard, Boris is right - we missed the 1.2b train. Please try to use the
workaround mentioned in comment 154 and see how you fare with it.
I believe to have noticed another complication with the red code.  For starters,
I can't recompile the JAR files after doing the necessary modifications through
the patch files.  If the files in the JAR aren't supposed to be modified, what
should I do concerning the patch?  Another thing I noticed with the dual Mozilla
build installations in Linux is that the English (US) Language Pack needed an
update.  The 1.2 Beta still used the 1.1 English (US) Localization files and I
think that's leading to the problem I'm experiencing.  The last thing I noticed
is that the red code doesn't show as the root user, but it does if I'm logged on
as the user.
Robert the "needs update" issue is being dealt with by kairo in bug 174989.
Seems like the release scripts keep missing brand.dtd and region.dtd and nobody
noticed this time around...

WRT to your issues with the patch in this bug - it would be of much greater
value, if you pulled the latest nightly build and verified that the problem goes
away :-)

http://ftp.mozilla.org/pub/mozilla/nightly/
jbetak@netscape.com , I downloaded the latest Linux i686 nightly of Mozilla and
although the two original lines of red code have been fixed, two more troubles
come up:

1. label="&redoCmd.label;" comes up in Red below the status bar when logged on
as the user.
2. The text box to input the web site can no longer be seen when logged in as
the user.

The language pack still says "needs update", when I checked the preferences. 
Would you recommend that a new bug with this situation be created?  Just in
case, I recommend that the Platform field should be modified from All to Linux
to show it's a Linux-only issue and the bug should be re-opened.  To reproduce,
just open Mozilla as a non-root user.
*** Bug 175636 has been marked as a duplicate of this bug. ***
Robert, thanks so much for helping with verification :-) Since the original
issue (red error code text displayed under status bar "key_irc") no longer
occurs on your system when using the latest trunk build, I'd leave this bug closed.

Please feel free to file new bugs for 1. and 2. I'm not sure whether they are
easily reproducible. It would be of great help if you saved your current profile
directory somewhere and then tried the workaround mentioned in comment 154. See
if it resolves these issues. 

Were you using the Polish language pack in version 1.1? Do you think you could
sanitize the profile directories (remove all private information) and make them
available, if the issues you reported turn out to be hard to reproduce? This bug
has very wide distribution and I'd recommend taking further discussion into the
new bugs to avoid spamming people.
Robert, if you used a different language pack than en-US for testing, your
comments are very clear: some texts were added, and as we don't fall back to any
default lagnuage, we end up in not finding the strings and have errors, as the
XML error about that Redo thingy or non-functioning windows.

The original bug seems to have gone though ;-)
I tried the profile creation method in comment 154 and now Mozilla 1.2+ Nightly
works.  Thank you!
*** Bug 177112 has been marked as a duplicate of this bug. ***
*** Bug 177301 has been marked as a duplicate of this bug. ***
*** Bug 177706 has been marked as a duplicate of this bug. ***
*** Bug 177883 has been marked as a duplicate of this bug. ***
*** Bug 177921 has been marked as a duplicate of this bug. ***
*** Bug 179781 has been marked as a duplicate of this bug. ***
*** Bug 180470 has been marked as a duplicate of this bug. ***
*** Bug 171332 has been marked as a duplicate of this bug. ***
*** Bug 183193 has been marked as a duplicate of this bug. ***
*** Bug 176646 has been marked as a duplicate of this bug. ***
*** Bug 149458 has been marked as a duplicate of this bug. ***
*** Bug 138477 has been marked as a duplicate of this bug. ***
Sorry, but it ain't fixed yet (as of 12/14/2002).
Ole, please file a new bug. You are seeing a problem similar in nature, but
unrelated to the fix we have put in place for Chatzilla. Please make sure to
mention some etiology (upgrade path, languages packs used etc.).

Have a look at comment 154, it should help you to work around the problem you
are seeing, and you should be able to use Mozilla again.
*** Bug 200440 has been marked as a duplicate of this bug. ***
Hi,
I have this problem, only that the error message is "<menuitem position="5"
label="&venkmanCmd.label;".
My Mozilla Version is 1.3.1

Actually I hvae no idea if I used this feedback form right; I hope I did ;)

Thank you,
M. Meiss
I think I got everyone back...
Manfred: actually, you did use it right, you removed everybody from the CC list
here :(

Anyway, this should be gone with newer versions of your beloved German Mozilla,
all 1.4 (Alpha, Beta, Final) builds should have fixed this, as they include a
venkman translation now.
If you removed the English translation from your Mozilla, it might be your
fault, else this is indeed a slightly different form of this bug, which
originally was about chatzilla...
oops, wanted to say "did *NOT* use it right"...

Sorry for spamming...
Think it's safe to verify this as fixed now. Certainly works, and no new dupes
for a little while...
Status: RESOLVED → VERIFIED
No longer blocks: majorbugs
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: