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)
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)
35.78 KB,
image/jpeg
|
Details | |
2.77 KB,
patch
|
rginda
:
review+
alecf
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
181.03 KB,
image/jpeg
|
Details |
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
Comment 4•22 years ago
|
||
To rginda. It looks like debugger/chatzilla is not installing locale stuff correctly...
Assignee: trudelle → rginda
Comment 5•22 years ago
|
||
*** Bug 130349 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•22 years ago
|
||
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.
Comment 7•22 years ago
|
||
bz, please see my last comment
Comment 8•22 years ago
|
||
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. :(
Comment 9•22 years ago
|
||
From the screenshot, it looks similiar to the problem described at http://slashdot.org/comments.pl?sid=29319&cid=3146725.
Comment 10•22 years ago
|
||
Emanuele, how did you install Mozilla?
Reporter | ||
Comment 11•22 years ago
|
||
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.
Comment 12•22 years ago
|
||
*** Bug 130574 has been marked as a duplicate of this bug. ***
Comment 13•22 years ago
|
||
Again: I don't think this has to do with chatzilla. Bug 127044 show similar screenshots.
Comment 14•22 years ago
|
||
Ok. Since people are seeing this with things other than chatzilla...
Assignee: rginda → trudelle
Severity: normal → major
Comment 15•22 years ago
|
||
*** Bug 130484 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
->Installer, per previous comments.
Assignee: trudelle → dveditz
Component: XP Apps → Installer
QA Contact: paw → bugzilla
Comment 17•22 years ago
|
||
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
Comment 18•22 years ago
|
||
I'm seeing this in nightly 20020314 on win95 installed from the zip file. Unzipped into a new directory, new profile.
Comment 19•22 years ago
|
||
also see new bug 131016
Comment 20•22 years ago
|
||
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
Comment 21•22 years ago
|
||
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?
Comment 22•22 years ago
|
||
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.
Updated•22 years ago
|
OS: Linux → All
Comment 23•22 years ago
|
||
->hewitt
Assignee: trudelle → hewitt
Component: XP Apps → XP Toolkit/Widgets: XUL
Comment 25•22 years ago
|
||
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...
Comment 26•22 years ago
|
||
The "bad" one has embed.jar listed in installed-chrome.txt
Comment 27•22 years ago
|
||
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.
Comment 28•22 years ago
|
||
*** Bug 131958 has been marked as a duplicate of this bug. ***
Comment 29•22 years ago
|
||
*** Bug 132029 has been marked as a duplicate of this bug. ***
Comment 30•22 years ago
|
||
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.
Comment 31•22 years ago
|
||
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
Reporter | ||
Comment 32•22 years ago
|
||
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.
Comment 33•22 years ago
|
||
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.
Comment 34•22 years ago
|
||
*** Bug 132560 has been marked as a duplicate of this bug. ***
Comment 35•22 years ago
|
||
I installed a new profile, all right. Now some expert on mozilla profiles could help me
Comment 36•22 years ago
|
||
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.
Comment 37•22 years ago
|
||
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
Comment 38•22 years ago
|
||
I've had people report this to me with old profiles as well.
Comment 39•22 years ago
|
||
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.
Comment 40•22 years ago
|
||
forgot to mention, also tried old,new profiles as well, but to no avail.
Reporter | ||
Comment 42•22 years ago
|
||
The same with RC1. I could solve only not installing debugger and chatzilla
Comment 43•22 years ago
|
||
*** Bug 138510 has been marked as a duplicate of this bug. ***
Comment 44•22 years ago
|
||
*** Bug 138843 has been marked as a duplicate of this bug. ***
Comment 45•22 years ago
|
||
*** Bug 138510 has been marked as a duplicate of this bug. ***
Comment 46•22 years ago
|
||
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
Comment 47•22 years ago
|
||
*** Bug 142595 has been marked as a duplicate of this bug. ***
Comment 48•22 years ago
|
||
*** Bug 143478 has been marked as a duplicate of this bug. ***
Comment 49•22 years ago
|
||
*** Bug 143002 has been marked as a duplicate of this bug. ***
Comment 50•22 years ago
|
||
*** Bug 144038 has been marked as a duplicate of this bug. ***
Comment 51•22 years ago
|
||
*** Bug 145232 has been marked as a duplicate of this bug. ***
Comment 52•22 years ago
|
||
*** Bug 147149 has been marked as a duplicate of this bug. ***
Comment 53•22 years ago
|
||
*** Bug 147140 has been marked as a duplicate of this bug. ***
Comment 54•22 years ago
|
||
*** Bug 147219 has been marked as a duplicate of this bug. ***
Comment 55•22 years ago
|
||
*** Bug 147233 has been marked as a duplicate of this bug. ***
Comment 56•22 years ago
|
||
*** Bug 147769 has been marked as a duplicate of this bug. ***
Comment 57•22 years ago
|
||
*** Bug 151175 has been marked as a duplicate of this bug. ***
Comment 58•22 years ago
|
||
*** Bug 151356 has been marked as a duplicate of this bug. ***
Comment 59•22 years ago
|
||
*** Bug 151953 has been marked as a duplicate of this bug. ***
Comment 60•22 years ago
|
||
*** Bug 153328 has been marked as a duplicate of this bug. ***
Comment 61•22 years ago
|
||
*** Bug 154510 has been marked as a duplicate of this bug. ***
Comment 62•22 years ago
|
||
*** Bug 154553 has been marked as a duplicate of this bug. ***
Comment 63•22 years ago
|
||
*** Bug 154527 has been marked as a duplicate of this bug. ***
Comment 64•22 years ago
|
||
*** Bug 155572 has been marked as a duplicate of this bug. ***
Comment 65•22 years ago
|
||
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.
Comment 66•22 years ago
|
||
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>
Comment 67•22 years ago
|
||
*** Bug 158817 has been marked as a duplicate of this bug. ***
Summary: Strange front-end in 0.9.9 → Strange front-end in 0.9.9 ("key_irc")
Comment 68•22 years ago
|
||
i have the same till version 1.1alpha, prior i installed netscape 7pr1 can the install of ns 7pr1 the reason for this prob?
Comment 69•22 years ago
|
||
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!
Comment 70•22 years ago
|
||
*** Bug 144328 has been marked as a duplicate of this bug. ***
Comment 71•22 years ago
|
||
*** Bug 159491 has been marked as a duplicate of this bug. ***
Comment 72•22 years ago
|
||
*** Bug 159517 has been marked as a duplicate of this bug. ***
Comment 73•22 years ago
|
||
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?
Comment 74•22 years ago
|
||
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.
Comment 75•22 years ago
|
||
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.
Comment 77•22 years ago
|
||
*** Bug 161544 has been marked as a duplicate of this bug. ***
Comment 78•22 years ago
|
||
*** Bug 161653 has been marked as a duplicate of this bug. ***
Comment 79•22 years ago
|
||
*** Bug 158814 has been marked as a duplicate of this bug. ***
Comment 80•22 years ago
|
||
Nav triage team: nsbeta1+/adt3
Comment 81•22 years ago
|
||
*** Bug 163600 has been marked as a duplicate of this bug. ***
Comment 82•22 years ago
|
||
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.
Comment 83•22 years ago
|
||
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.
Comment 84•22 years ago
|
||
*** Bug 163600 has been marked as a duplicate of this bug. ***
Comment 85•22 years ago
|
||
*** Bug 163999 has been marked as a duplicate of this bug. ***
Comment 86•22 years ago
|
||
*** Bug 164775 has been marked as a duplicate of this bug. ***
Comment 87•22 years ago
|
||
*** Bug 164770 has been marked as a duplicate of this bug. ***
Comment 88•22 years ago
|
||
ccing tao, per comment 82. Who else would know about this localeVersion stuff?
Comment 89•22 years ago
|
||
*** Bug 164831 has been marked as a duplicate of this bug. ***
Comment 90•22 years ago
|
||
bz: perhaps the people who originally implemented that localeVersion stuff? (not sure who did that though...)
Comment 91•22 years ago
|
||
*** Bug 164922 has been marked as a duplicate of this bug. ***
Comment 92•22 years ago
|
||
*** Bug 165125 has been marked as a duplicate of this bug. ***
Comment 93•22 years ago
|
||
*** Bug 165341 has been marked as a duplicate of this bug. ***
Comment 94•22 years ago
|
||
*** Bug 165415 has been marked as a duplicate of this bug. ***
Comment 95•22 years ago
|
||
*** Bug 165527 has been marked as a duplicate of this bug. ***
Comment 96•22 years ago
|
||
*** Bug 165675 has been marked as a duplicate of this bug. ***
Comment 97•22 years ago
|
||
*** Bug 165675 has been marked as a duplicate of this bug. ***
Comment 98•22 years ago
|
||
*** Bug 165773 has been marked as a duplicate of this bug. ***
Comment 99•22 years ago
|
||
*** Bug 165913 has been marked as a duplicate of this bug. ***
Comment 100•22 years ago
|
||
This is for the 1.0.1 branch, it will have to be updated for the tip.
Comment 101•22 years ago
|
||
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.
Comment 102•22 years ago
|
||
Oh. So far the only l10n I've seen that fixes this is the zh-CN translation for 1.0.1.
Comment 103•22 years ago
|
||
*** Bug 166058 has been marked as a duplicate of this bug. ***
Comment 104•22 years ago
|
||
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?
Comment 105•22 years ago
|
||
They are different things, iirc. 1.0.1 is going to ship with 1.0.1rc1. Blame the build team. :)
Comment 106•22 years ago
|
||
Comment on attachment 97418 [details] [diff] [review] patch that adds localeVersion to chatzilla r=rginda
Attachment #97418 -
Flags: review+
Comment 107•22 years ago
|
||
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>
Comment 108•22 years ago
|
||
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.
Comment 109•22 years ago
|
||
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. :(
Comment 110•22 years ago
|
||
*** Bug 166532 has been marked as a duplicate of this bug. ***
Comment 111•22 years ago
|
||
*** Bug 166537 has been marked as a duplicate of this bug. ***
Comment 112•22 years ago
|
||
*** Bug 166237 has been marked as a duplicate of this bug. ***
Comment 113•22 years ago
|
||
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?
Comment 114•22 years ago
|
||
*** Bug 168141 has been marked as a duplicate of this bug. ***
Comment 115•22 years ago
|
||
*** Bug 168192 has been marked as a duplicate of this bug. ***
Comment 116•22 years ago
|
||
*** Bug 168207 has been marked as a duplicate of this bug. ***
Comment 117•22 years ago
|
||
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")
Comment 118•22 years ago
|
||
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.
Comment 119•22 years ago
|
||
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’t experience the “red code” problem despite of this. My personal bookmarks, mailbox folders etc. are still there and were “imported” into 1.2a and the “old” 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?
Comment 120•22 years ago
|
||
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)
Comment 121•22 years ago
|
||
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.
Comment 122•22 years ago
|
||
*** Bug 169237 has been marked as a duplicate of this bug. ***
Comment 123•22 years ago
|
||
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.
Comment 124•22 years ago
|
||
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.).
Comment 125•22 years ago
|
||
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...) :(
Comment 126•22 years ago
|
||
I'm aware of bug 142623. That's an entirely different issue, no? So don't add unrelated comments to this bug.
Comment 127•22 years ago
|
||
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.
Comment 128•22 years ago
|
||
*** Bug 169903 has been marked as a duplicate of this bug. ***
Comment 129•22 years ago
|
||
*** Bug 150180 has been marked as a duplicate of this bug. ***
Comment 130•22 years ago
|
||
*** Bug 166484 has been marked as a duplicate of this bug. ***
Comment 131•22 years ago
|
||
*** Bug 170307 has been marked as a duplicate of this bug. ***
Comment 132•22 years ago
|
||
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...
Comment 133•22 years ago
|
||
*** Bug 170926 has been marked as a duplicate of this bug. ***
Comment 134•22 years ago
|
||
*** Bug 171039 has been marked as a duplicate of this bug. ***
Comment 135•22 years ago
|
||
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
Comment 136•22 years ago
|
||
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
Comment 137•22 years ago
|
||
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
Comment 138•22 years ago
|
||
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
Comment 139•22 years ago
|
||
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.
Comment 140•22 years ago
|
||
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.
Comment 141•22 years ago
|
||
*** Bug 171988 has been marked as a duplicate of this bug. ***
Comment 142•22 years ago
|
||
*** Bug 172133 has been marked as a duplicate of this bug. ***
Comment 143•22 years ago
|
||
*** Bug 172492 has been marked as a duplicate of this bug. ***
Comment 144•22 years ago
|
||
*** Bug 172471 has been marked as a duplicate of this bug. ***
Comment 145•22 years ago
|
||
Problem fixed: 1. Uninstall Mozilla 2. reboot 3. Install new Mozilla version into other directory --> all bookmarks and mails are available
Assignee: jbetak → hyatt
Assignee | ||
Comment 147•22 years ago
|
||
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
Comment 148•22 years ago
|
||
For now i have un-install an dre-install with-out Bugzilla and chatzilla and all is ok. RG
Comment 149•22 years ago
|
||
*** Bug 173544 has been marked as a duplicate of this bug. ***
Comment 150•22 years ago
|
||
*** Bug 173544 has been marked as a duplicate of this bug. ***
Comment 151•22 years ago
|
||
*** Bug 173712 has been marked as a duplicate of this bug. ***
Comment 152•22 years ago
|
||
*** Bug 173926 has been marked as a duplicate of this bug. ***
Comment 153•22 years ago
|
||
*** Bug 174099 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 154•22 years ago
|
||
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
Comment 155•22 years ago
|
||
> 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).
Updated•22 years ago
|
Assignee | ||
Comment 156•22 years ago
|
||
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...
Assignee | ||
Comment 157•22 years ago
|
||
Attachment #97418 -
Attachment is obsolete: true
Assignee | ||
Comment 158•22 years ago
|
||
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.
Assignee | ||
Comment 159•22 years ago
|
||
would anyone care to r= & sr=?
Whiteboard: [adt3] → [adt3] have patch / need r=/sr=/a=
Comment 160•22 years ago
|
||
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.
Comment 161•22 years ago
|
||
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 162•22 years ago
|
||
Comment on attachment 103101 [details] [diff] [review] new patch (mimics blizzard's approach) sr=alecf
Attachment #103101 -
Flags: superreview+
Comment 163•22 years ago
|
||
*** Bug 175040 has been marked as a duplicate of this bug. ***
Comment 164•22 years ago
|
||
Comment on attachment 103101 [details] [diff] [review] new patch (mimics blizzard's approach) r=rginda
Attachment #103101 -
Flags: review+
Comment 165•22 years ago
|
||
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+
Assignee | ||
Comment 166•22 years ago
|
||
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
Comment 167•22 years ago
|
||
*** Bug 175151 has been marked as a duplicate of this bug. ***
Comment 168•22 years ago
|
||
*** Bug 175228 has been marked as a duplicate of this bug. ***
Comment 169•22 years ago
|
||
*** Bug 175496 has been marked as a duplicate of this bug. ***
Comment 170•22 years ago
|
||
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 → ---
Comment 171•22 years ago
|
||
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 ago → 22 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 172•22 years ago
|
||
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.
Comment 173•22 years ago
|
||
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.
Assignee | ||
Comment 174•22 years ago
|
||
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/
Comment 175•22 years ago
|
||
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.
Comment 176•22 years ago
|
||
*** Bug 175636 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 177•22 years ago
|
||
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.
Comment 178•22 years ago
|
||
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 ;-)
Comment 179•22 years ago
|
||
I tried the profile creation method in comment 154 and now Mozilla 1.2+ Nightly works. Thank you!
Comment 180•22 years ago
|
||
*** Bug 177112 has been marked as a duplicate of this bug. ***
Comment 181•22 years ago
|
||
*** Bug 177301 has been marked as a duplicate of this bug. ***
Comment 182•22 years ago
|
||
*** Bug 177706 has been marked as a duplicate of this bug. ***
Comment 183•22 years ago
|
||
*** Bug 177883 has been marked as a duplicate of this bug. ***
Comment 184•22 years ago
|
||
*** Bug 177921 has been marked as a duplicate of this bug. ***
Comment 185•22 years ago
|
||
*** Bug 179781 has been marked as a duplicate of this bug. ***
Comment 186•22 years ago
|
||
*** Bug 180470 has been marked as a duplicate of this bug. ***
Comment 187•22 years ago
|
||
*** Bug 171332 has been marked as a duplicate of this bug. ***
Comment 188•22 years ago
|
||
*** Bug 183193 has been marked as a duplicate of this bug. ***
Comment 189•22 years ago
|
||
*** Bug 176646 has been marked as a duplicate of this bug. ***
Comment 190•22 years ago
|
||
*** Bug 149458 has been marked as a duplicate of this bug. ***
Comment 191•22 years ago
|
||
*** Bug 138477 has been marked as a duplicate of this bug. ***
Comment 192•22 years ago
|
||
Sorry, but it ain't fixed yet (as of 12/14/2002).
Assignee | ||
Comment 193•22 years ago
|
||
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.
Comment 194•21 years ago
|
||
*** Bug 200440 has been marked as a duplicate of this bug. ***
Comment 195•21 years ago
|
||
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
Comment 196•21 years ago
|
||
I think I got everyone back...
Comment 197•21 years ago
|
||
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...
Comment 198•21 years ago
|
||
oops, wanted to say "did *NOT* use it right"... Sorry for spamming...
Comment 199•21 years ago
|
||
Think it's safe to verify this as fixed now. Certainly works, and no new dupes for a little while...
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•