Closed Bug 246014 Opened 20 years ago Closed 20 years ago

Extension manager does not generate appropriate chrome.rdf entries for locale entities

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: kakadu+bugzilla, Assigned: benjamin)

References

Details

(Keywords: fixed-aviary1.0, Whiteboard: [have patch])

Attachments

(6 files, 2 obsolete files)

install manifest for Tabbrowser Preferences 0.5.1
1.54 KB, text/plain
Details
install manifest for Download Manager Tweak 0.4.3.1
1.32 KB, text/plain
Details
install manifest for Web Developer 0.8
1.43 KB, text/plain
Details
patch
1.74 KB, patch
Details | Diff | Splinter Review
updated with latest dss-disablement
94.82 KB, patch
bugs
: superreview+
bugs
: approval-aviary+
Details | Diff | Splinter Review
Separate seamonkey-only CR methods into a separate interface
26.84 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+ (daihard: XFT+GTK2; opt. for P4/SSE-2) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+ (daihard: XFT+GTK2; opt. for P4/SSE-2) After installing my repackaged Tabbrowser Preferences extension listed above, the new Extension Manager does not create the appropriate chrome.rdf entries for the locale entity files. This makes the files go missing and causes XUL errors when the preferences page is loaded, either via a chrome:// URL or via the Manager. An appeal on MozillaZine got this sharp-eyed response from someone named twanno: the selectedLocale tag was missing from the autogenerated chrome.rdf file in our profiles. Adding this tag fixes the XUL errors and allows the preferences dialog to appear. The following is a broken entry that causes the XUL errors: <RDF:Description RDF:about="urn:mozilla:package:tabprefs" c:baseURL="jar:file:///home/bhchapm/.mozilla/firefox/IKEA/extensions/%7B9b9d2aaa-ae26-4447-a7a1-633a32b19ddd%7D/chrome/tabprefs.jar!/content/tabprefs/" c:locType="profile" c:displayName="Tabbrowser Preferences 0.5.1" c:author="Chris Cook (tangent@intraplanar.net)" c:authorURL="http://www.intraplanar.net/projects/tabprefs/" c:settingsURL="chrome://tabprefs/content/pref-tabprefs.xul" c:extension="true" c:description="Enables enhanced control for tabbed browsing." c:name="tabprefs"/> And this is a working entry that does not cause any errors: <RDF:Description RDF:about="urn:mozilla:package:tabprefs" c:baseURL="jar:file:///home/bhchapm/.mozilla/firefox/IKEA/extensions/%7B9b9d2aaa-ae26-4447-a7a1-633a32b19ddd%7D/chrome/tabprefs.jar!/content/tabprefs/" c:locType="profile" c:displayName="Tabbrowser Preferences 0.5.1" c:author="Chris Cook (tangent@intraplanar.net)" c:authorURL="http://www.intraplanar.net/projects/tabprefs/" c:settingsURL="chrome://tabprefs/content/pref-tabprefs.xul" c:extension="true" c:description="Enables enhanced control for tabbed browsing." c:name="tabprefs"> <c:selectedLocale RDF:resource="urn:mozilla:locale:en-US:tabprefs"/> </RDF:Description> twanno also reported that the selectedLocale entry was created correctly when his profile contained existing extensions, and was not created after he tried with a fresh profile. AFAIK there are no RDF errors in my extension anywhere. Reproducible: Always Steps to Reproduce: 1. Install an Aviary Firefox build. 2. Install my repackaged Tabbrowser Preferences extension in the normal way. 3. Attempt to open the Preferences dialog. Actual Results: XML Parsing Error: undefined entity Location: chrome://tabprefs/conpref-tabprefstent.xul Line Number 7, Column 1: <dialog id=''pref-tabprefs Expected Results: Open the dialog without any errors and allow me to configure the extension. I am unsure of what severity this should have - if it is a problem with my extension, then this bug is INVALID of course.
chrome://tabprefs/content/pref-tabprefs.xul is the appropriate URL. The error message became garbled in some way.
I believe this can be closed as INVALID now. I just reproduced this exact problem with another extension I repackaged: http://www.pryan.org/mozilla/site/TheOneKEA/downloadtweak_0431.xpi This extension also shows the exact same preferences error (and also cripples the DM entirely) until the appropriate selectedLocale tag is added to chrome.rdf. Broken: <RDF:Description RDF:about="urn:mozilla:package:downloadmgr" c:baseURL="jar:file:///home/bhchapm/.mozilla/firefox/TheOneIKEA/extensions/%7B19ec84db-7357-47a5-b415-93b6dc31bec3%7D/chrome/downloadmgr.jar!/content/downloadmgr/" c:locType="profile" c:displayName="Download Manager Tweak" c:author="andman42" c:authorURL="http://dmextension.mozdev.org/" c:name="downloadmgr" c:extension="true" c:description="Makes the Firefox download manager sleeker and more concise." c:settingsURL="chrome://downloadmgr/content/options/options.xul"> <c:selectedSkin RDF:resource="urn:mozilla:skin:classic/1.0:downloadmgr"/> </RDF:Description> Working: <RDF:Description RDF:about="urn:mozilla:package:downloadmgr" c:baseURL="jar:file:///home/bhchapm/.mozilla/firefox/TheOneIKEA/extensions/%7B19ec84db-7357-47a5-b415-93b6dc31bec3%7D/chrome/downloadmgr.jar!/content/downloadmgr/" c:locType="profile" c:displayName="Download Manager Tweak" c:author="andman42" c:authorURL="http://dmextension.mozdev.org/" c:name="downloadmgr" c:extension="true" c:description="Makes the Firefox download manager sleeker and more concise." c:settingsURL="chrome://downloadmgr/content/options/options.xul"> <c:selectedLocale RDF:resource="urn:mozilla:locale:en-US:downloadmgr"/> <c:selectedSkin RDF:resource="urn:mozilla:skin:classic/1.0:downloadmgr"/> </RDF:Description> Yet I am certain that my install manifests are correct. What is happening here?
The install manifest for Tabbrowser Preferences 0.5.1.
The install manifest for Download Manager Tweak 0.4.3.1.
Attachment #150350 - Attachment mime type: text/rdf → text/plain
Attachment #150351 - Attachment mime type: text/rdf → text/plain
Flags: blocking0.9?
The install manifest for Web Developer 0.8. After installing this and restarting, selectedLocale is missing: <RDF:Description RDF:about="urn:mozilla:package:webdeveloper" c:baseURL="jar:file:///home/bhchapm/.mozilla/firefox/TheOneIKEA/extensions/%7Bc45c406e-ab73-11d8-be73-000a95be3b12%7D/chrome/webdeveloper.jar!/content/webdeveloper/" c:locType="profile" c:author="Chris Pederick" c:authorURL="http://www.chrispederick.com/work/firefox/webdeveloper/" c:description="Adds a menu and a toolbar with various web developer tools." c:displayName="Web Developer 0.8" c:extension="true" c:name="webdeveloper" c:settingsURL="chrome://webdeveloper/content/options/options.xul"> <c:selectedSkin RDF:resource="urn:mozilla:skin:classic/1.0:webdeveloper"/> </RDF:Description> Adding it nets the desired result: <RDF:Description RDF:about="urn:mozilla:package:webdeveloper" c:baseURL="jar:file:///home/bhchapm/.mozilla/firefox/TheOneIKEA/extensions/%7Bc45c406e-ab73-11d8-be73-000a95be3b12%7D/chrome/webdeveloper.jar!/content/webdeveloper/" c:locType="profile" c:author="Chris Pederick" c:authorURL="http://www.chrispederick.com/work/firefox/webdeveloper/" c:description="Adds a menu and a toolbar with various web developer tools." c:displayName="Web Developer 0.8" c:extension="true" c:name="webdeveloper" c:settingsURL="chrome://webdeveloper/content/options/options.xul"> <c:selectedLocale RDF:resource="urn:mozilla:locale:en-US:webdeveloper"/> <c:selectedSkin RDF:resource="urn:mozilla:skin:classic/1.0:webdeveloper"/> </RDF:Description> blocking0.9? indeed.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040609 Firefox/0.8.0+ (daihard: XFT+GTK2; opt. for P4/SSE-2) Confirmed again with three extensions: Bookmarks FTP, Search Button and Popup Count. Statusbar Clock also shows this bug, but it has other issues that preclude it from being included.
Confirmed yet again with Browser Uptime. User Agent Switcher showed the same issue as Statusbar Clock, even after manually editing chrome.rdf. All three extensions were missing both locale AND skin tags AND the c:extension property. Broken Browser Uptime entry (typical of all three): <RDF:Description RDF:about="urn:mozilla:package:uptime" c:baseURL="jar:file:///home/bhchapm/.mozilla/firefox/TheOneIKEA/extensions/%7B34003ce0-b051-11d8-92e7-00d09e0179f2%7D/chrome/uptime.jar!/content/uptime/" c:locType="profile" c:name="uptime"/> Working Browser Uptime entry (again, typical): <RDF:Description RDF:about="urn:mozilla:package:uptime" c:baseURL="jar:file:///home/bhchapm/.mozilla/firefox/TheOneIKEA/extensions/%7B34003ce0-b051-11d8-92e7-00d09e0179f2%7D/chrome/uptime.jar!/content/uptime/" c:locType="profile" c:extension="true" c:name="uptime"> <c:selectedLocale RDF:resource="urn:mozilla:locale:en-US:uptime"/> <c:selectedSkin RDF:resource="urn:mozilla:skin:classic/1.0:uptime"/> </RDF:Description> I don't know what else to do here.
I just went back and created a new profile and reinstalled most of these extensions, and experienced no errors. I'm not sure how to reproduce this bug now.
OK, this is definitely related somehow to the profile machinery and its interaction with the EM - I went and created a totally new profile and installed TBP, and it was broken in the manner I have described. I then went and installed Bookmarks FTP and it too was broken in the manner described - it even threw the following JS error on startup: [Exception... "Component returned failure code: 0x804b000a [nsIStringBundle.GetStringFromName]" nsresult: "0x804b000a (<unknown>)" location: "JS frame :: XStringBundle :: getString :: line 16" data: no] My other profile, which I loaded my settings into (db files, cookies, manifests, prefs, etc) and installed a number of extensions into, was NOT broken. TBP and BMFTP both worked perfectly on the first try. I can reproduce this 100% of the time now, in the manner described, with a totally clean profile.
I get this on Windows too Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+ I did some testing about this and I found out that this didn't occure when I started the browser with a fresh profile and downloaded the extensions to my computer and then installed by draging the extension(s) onto the browser. I did not change any preferences before installing the extension, except to not be my default browser, what is been asked on start-up. After restarting I could not find any errors But this did occur when I changed some prefs first before installing the extensions, same build new profile: First I went to tools->options, there I changed: * Advanced -> Hide tabbar when only one website is open (unchecked it) * Advanced -> Use smooth scrolling (checked it) * downloads -> ask me where to save every file * web features -> enable java (unchecked it) then i clicked OK in the options dialog. then I opened a tab with ctrl+t and dragged the extension(s) onto the browser. After restarting the xml parsing errors were there. I will test futher to see if only one change to tools -> options is responsible or more are.
I'm sorry I was totally wrong about the preferences. I was able to reproduce a good installation two times this far, the other dozen times it gave me the error. The only two times I was able to have a good installation I did this: (I will try be as accurate as possible) 1) start up browser (no prefious profiles, phoenix profile renamed->(0.8 is my default browser)). 2) I get the question to enable it as my default browser i uncheck the always check option and i click no 3) browser starts up, firefox homepage appears 4) open new tab ctrl+t type in location bar forums.mozillazine.org, got to firefox builds, go to peter(6)'s thread, click on the link to this bug in the thread 5) this bug opens in a new window 6) the first time i downloaded the first two extensions named in this bug (tabprefs and downloadtweak) to my desktop. The second time they were allready there 7) I minimized the second window, then I minimized the first window, then I reshowed the second window and moved it to the right of my screen 8) I dragged the extensions in the second window, they show up in the theme manager, I closed the theme manager 9) I closed the second window, then I closed the first window after bringing it up again, it asks to close all tabs, I uncheck the option of allways check before close and allow 10) I restart firefox and I open the extensionmanager and click on options of the extension, I get no error and the optionsdialog shows where I otherwise would get a xml parse error. The other times I did try to only minimize the window and bring it up agian before dragging the extension or only drag the extensions in the second window without minimizing it first and some other things like this, but I had no succes thus far
Changing OS to All, as per comment 10.
OS: Linux → All
Is this related? 1) Install an extension which has a locale 2) Close and reopen Firefox, check that the extension works 3) Install the extension again, without uninstalling 4) Close and reopen Firefox 5) You should get a lovely XUL/XML parsing error related to entities used. Can anyone confirm/deny/point me to an existing report? If you wish to test, you can try this: http://extensions.cusser.net/imagetoolbar/imagetoolbar-0.3rc.xpi - note that the extension release isn't finished yet and this shouldn't be used by anyone for anything other than testing this bug. Uninstalling before reinstalling appears to stop this from occurring, but ideally this should never happen. Uninstalling will also fix this problem once it occurs, and everything is back to normal if you install again.
After installing Mr. Basson's extension into my test profile, the extension's preference dialog is broken. After installing it into my main profile, it is not broken. I can provide a full list of the files I regularly save when backing up my profile, in case it could make a difference.
(In reply to comment #9) > [Exception... "Component returned failure code: 0x804b000a > [nsIStringBundle.GetStringFromName]" nsresult: "0x804b000a (<unknown>)" > location: "JS frame :: XStringBundle :: getString :: line 16" data: no] I was getting this same garbage after installing some extensions to 0.9rc. I uninstalled (using Add/Remove) and reinstalled. The problem went away and did not come back. Although my first install was "clean" (having deleted the program and profile directories), I failed to follow the instruction to Unistall FF 0.8 using Add/Remove before installing 0.9rc. I wonder if that was a contributing factor. Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+
My first Aviary build installation was clean (the subsequent ones have not been), and I could still trigger the error (the build ID shown in comment 0 is the clean install). I'm fairly certain now that this probably has something to do with the EM and the way it deals with profiles.
Hmmmmm. I just created a fresh profile using the following build and installed some extensions, and there appear to be no locale errors. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040610 Firefox/0.8.0+ (daihard: XFT+GTK2; opt. for P4/SSE-2) If no one else reports any problems, I'll resolve this.
It still isn't resolved for me Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040610 Firefox/0.8.0+ zip build, w/ clean profile
I think this has something to do with bug http://bugzilla.mozilla.org/show_bug.cgi?id=244479 I got the xml parsing error when I had Tabbrowser Preferences installed and I didn't have a chrome/overlayinfo folder in my <appdir>. I then deleted my profile, started the browser and closed it again and then I deleted my <appdir>/chrome/chrome.rdf as mentioned in the bugreport of bug #244479. After restarting firefox, so chrome/overlayinfo/ was created, Tabprefs was installed without any problem. To reproduce I deleted my profile and I deleted chrome/overlayinfo again. and then I started firefox and reinstalled TabPrefs. I then restarted firefox and the xml parsing error again showed up when I wanted to view the options of Tab Prefs. If it indeed has anything to do with bug #244479, then one thing puzzles me, because I was able to install Tabprefs correctly for two times with zip build Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+ With this zip build (Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040610 Firefox/0.8.0+) I tried to install only once with the error as result, before I found out that I was suffering from bug #244479. And I'm pretty sure that help contents was also not available in the help menu of the previous build.
As of 20040610 Branch, I no longer experience the problem I mentioned in comment 13
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040611 Firefox/0.8.0+ (daihard: XFT+GTK2; opt. for P4/SSE-2) I installed TBP into a freshly created profile and got the XML error as usual.
Please read this comment. Provide information how to localize Firefox 0.9 http://bugzilla.mozilla.org/show_bug.cgi?id=245831#c22
(In reply to comment #22) > Please read this comment. > > Provide information how to localize Firefox 0.9 > http://bugzilla.mozilla.org/show_bug.cgi?id=245831#c22 > Your description of this problem sounds exactly like what I have found in this bug, especially since you are installing locales via XPIs. Perhaps this bug should be added to the dependency tree for bug 245831.
This problem is occurring with the final 0.9 release avaliable at the site. I would like to urge developers to make a new release avaliable as soon as possible, given the number of bugs that are arising from this final version. I am also experiencing various dialog boxes with no text (not even in the buttons), no automatic theme installation, and the 'Use autoscrolling' box has just grayed out for no apparent reason... I believe these are all serious issues that impact Firefox's usability. My apologies for the rant, but I believe there issues are serious.
(In reply to comment #24) > This problem is occurring with the final 0.9 release avaliable at the site. Please post your UA - so far it is only confirmed to happen on Win9x and Linux. If it happens on Win2K and WinXP, the OS:All setting will be justified. The rest of your rant is OT though.
Changing blocking0.9? to blocking1.0? since 0.9 is out and the issue is still present.
Flags: blocking0.9? → blocking1.0?
I was about to do that ;-) Anyway, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 (daihard: XFT+GTK2; opt. for P4/SSE-2) does indeed have the bug. A fresh profile and a fresh install of both TBP and Web Developer are both broken. My main profile, which was updated with these files before extension installation: bookmarks.html bookmarks.xml cookies.txt downloads.rdf formhistory.dat history.dat hostperm.1 localstore.rdf mimeTypes.rdf panels.rdf prefs.js search.rdf user.js Is not.
i can confirm this. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
>Please post your UA - so far it is only confirmed to happen on Win9x and Linux. >If it happens on Win2K and WinXP, the OS:All setting will be justified. It is happening on WinXP SP1, English version, and it was an upgrade from 0.8. Thank you, Andre
Also happens in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 WinXP SP1 I have tried uninstalling Firefox in Add/Remove programmes and deleting the folder from Program Files.
I had installed TBP, then uninstalled it due to the same problem. Now, when I try to install other extensions (All-in 1 gesture), I have the same problem, with this error message "XML phrasing error, unidentified entry: Location : Chrome://allinonegest/content/aioOptions.xul, line number 41, column 1: <dialog id='allInOnePref".
(In reply to comment #31) > I had installed TBP, then uninstalled it due to the same problem. Now, when I > try to install other extensions (All-in 1 gesture), I have the same problem, > with this error message > > "XML phrasing error, unidentified entry: Location : > Chrome://allinonegest/content/aioOptions.xul, line number 41, column 1: <dialog > id='allInOnePref". Yup. It's failing to parse correctly because the broken chrome.rdf is preventing Gecko from reading the extension's locale information, which breaks the XML tag attributes, and by extension, the entire XUL file. What's your UA?
With a clean installation of the latest Firefox build and Tabbrowser Preferences 0.5.4 there is no problem anymore.
(In reply to comment #33) > With a clean installation of the latest Firefox build and Tabbrowser Preferences > 0.5.4 there is no problem anymore. How clean? Did you modify any prefs or copy any saved settings into your profile directory before installing extensions? Comment 27 has a list of the files I regularly save when backing up my profile - did you save any of those files and restore them?
(In reply to comment #34) > (In reply to comment #33) > > With a clean installation of the latest Firefox build and Tabbrowser Preferences > > 0.5.4 there is no problem anymore. > > How clean? Did you modify any prefs or copy any saved settings into your profile > directory before installing extensions? Comment 27 has a list of the files I > regularly save when backing up my profile - did you save any of those files and > restore them? No, I didn't save anything. I uninstalled Ff and deleted my profile. I didn't copy saved settings in my profile, but I changed many preferencies in ptions.
(In reply to comment #35) > No, I didn't save anything. I uninstalled Ff and deleted my profile. I didn't > copy saved settings in my profile, but I changed many preferencies in ptions. Ah! I wonder if modifying prefs causes subtle things to change in one of the profile's configuration files that subsequently "fixes" the problem. I tried this with a fresh profile on my current 0.9-equivalent Linux build and was unable to reproduce this magic "fixing" effect. According to http://bugzilla.mozilla.org/describekeywords.cgi, the qawanted keyword can be used when more information is needed to help solve a particular problem. Thus, adding qawanted. If anybody can reproduce this, please let the bug know.
Keywords: qawanted
(In reply to comment #36) > (In reply to comment #35) > > No, I didn't save anything. I uninstalled Ff and deleted my profile. I didn't > > copy saved settings in my profile, but I changed many preferencies in ptions. > > Ah! > > I wonder if modifying prefs causes subtle things to change in one of the > profile's configuration files that subsequently "fixes" the problem. I tried > this with a fresh profile on my current 0.9-equivalent Linux build and was > unable to reproduce this magic "fixing" effect. > > According to http://bugzilla.mozilla.org/describekeywords.cgi, the qawanted > keyword can be used when more information is needed to help solve a particular > problem. Thus, adding qawanted. If anybody can reproduce this, please let the > bug know. My operating system is wondows xp, maybe that makes a difference.
Confirmed for me using Windows XP SP1a English Clean Install, Clean Profile User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 Using Installer Build, Custom Install, with Talkback enabled.
I can confirm Win XP - New profile, clean install (never on this machine before hand) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 I am also witnessing the same behaviour with Bookmarks Syncronizer - using the version on update.mozilla.org
The same problem (new install, new profile) 0.9 And there are some things that doesn't work either after installation of subj. 1. RSS extension. 2. Also "View Saved passwords..." 3. "Options" for all extensions No offence please, I really appreciate your work, but why did you call this version "release" ?
(In reply to comment #40) > The same problem (new install, new profile) 0.9 > > And there are some things that doesn't work either after installation of subj. > > 2. Also "View Saved passwords..." OUCH. Confirmed on my 0.9-equivalent Linux build. According to http://bugzilla.mozilla.org/bug_status.html#severity, a severity of major can be used for a major loss of function. Thus, changing severity to major.
Severity: normal → major
Addendum: Most of the pippki XUL is also broken by this bug - the CRL Manager, the certificate manager and the security manager that are accessed from the Advanced panel of Preferences/Options are all broken. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 (daihard: XFT+GTK2; opt. for P4/SSE-2) So what component does this bug belong under now?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 (daihard: XFT+GTK2; opt. for P4/SSE-2) I can no longer reproduce the problem, using a fresh profile and fresh installs of Web Developer and TBP.
It also happen with X extension. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 (daihard: XFT+GTK2; opt. for P4/SSE-2) I returned to this build and began to create clean profiles and install various extensions into them, and was only able to reliably reproduce the bug with TBP. I'm wondering if this may be a bug in TBP after all.
This is a serious problem in the main release (0.9 gtk2+xft, Linux). I'm seeing all the errors listed in this thread. Such as: Almost all extensions are broken now (see above). Auto-theme install is broken (though you can do it via the browse+install buttons on the web site). 'Save this password' dialogue is broken (see above). This issue should have blocked the 0.9 release, and *must* now block 1.0.
As to comment #45, can Bradley Chapman check the AllInOne Gestures plugin with a fully clean install to verify if this is a per-extension thing that needs changing by authors (who need to be told this !) or a Firefox bug.
(In reply to comment #47) > As to comment #45, can Bradley Chapman check the AllInOne Gestures plugin with a > fully clean install to verify if this is a per-extension thing that needs > changing by authors (who need to be told this !) or a Firefox bug. I was unable to break a clean profile produced by a 0.9-equivalent 20040614 branch build by installing AiO.
Flags: blocking1.0? → blocking1.0+
I exhibit the same problems as comment #46. After installing any version of TabbedBrowser Preferences from the version on mozilla update to 0.5.4 all of problems occurred. Uninstalling TBP had no effect as it seemed some of the locale entries remained in chrome.rdf. The only way I was able to restore functionality was to delete and start with a new profile. Eventually I was able to get TBP to work by stripping all of the locale data from the xpi and repacking it. After installing this repacked version: none of the problems happened. All of the other extensions I installed work, themes work, and the view saved password/save password dialogue work. Additionally I tried the purported fix of appending <c:selectedLocale RDF:resource="urn:mozilla:locale:en-US:tabprefs"/> to the section of TBP in my chrome.rdf but in addition to all of the problems above parts of extension manager became unclickable and it was required to force quit. After uninstalling TBP 0.5.4 the problems are still present view saved passwords for example shows an entity xml error. Upon doing a diff between the chrome.rdf after the uninstall and the preinstall chrome.rdf all of the locale settings added by TBP are still there. Switching back to the preinstall chrome.rdf restores functionality. In addition, after removing TBP 0.5.4 the following error presents on start-up: ******* EEEEEE = [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXULChromeRegistry.deselectLocaleForPackage]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///opt/firefox/components/nsExtensionManager.js :: anonymous :: line 987" data: no] I'm not sure if this helps or if the bug is within TBP or the method it uses to select locale data or within firefox, these are all just my observations from trying to get TBP working. UA: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9
sbkoh_sg@yahoo.com, I don't know who you are, and thus I don't believe you have the authority to set blocking1.0+. Resetting to blocking1.0?. Now then, has anybody managed to reproduce the bug with any extension other than TBP?
Flags: blocking1.0+ → blocking1.0?
A bit of an update: I've been trying to see why TBP works sometimes and other-times not. Based on a post in the extensionsmirror forum by Gert-Paul stating that installing webdeveloper 0.8 first, TBP 0.5.4 just worked. Upon looking in webdeveloper it installs just the en-US locale. After repacking TBP to install just the en-US locale it works flawlessly, no other xml entity errors (from other themes and view saved passwords and theme install works.) From another post by jooliaan on the extensionsmirror forum s/he installed TBP on a localised Italian version of Firefox 0.9 without incident. Perhaps this bug is related to not having a locale selected and attempting to install multiple locales? As a test for this: 1.Create new profile 2.Start firefox with ./firefox -P test9 -UILocale en-US -contentLocale US 3.Install TBP 0.5.4 4.Restart firefox specifying en-US and US 5.Everything works This seems to be the cause but I'm not sure how exactly to fix it.
I got the same errors, and after reading the comments... I decided to uninstall all my extensions and try again, but after uninstalling I changed my shortcut with wich I start Firefox to this: "D:\Mozilla Firefox\firefox.exe" -UILocale en-US -contentLocale US After that, every extension installs perfectly. So, the locale must be set for an extension to install properly. Somehow, there's no default locale or something.
In addition to my comment before: After setting the locale explicitly, the Save passwords dialog shows correctly again.
I have also witnessed this with bookmarks syncroniser can anyone confirm 0.9 windows
(In reply to comment #54) > I have also witnessed this with bookmarks syncroniser can anyone confirm > 0.9 windows > I also broke my profile with Bookmarks Synchronizer at a previous point. (In reply to comment #52) > I got the same errors, and after reading the comments... I decided to uninstall > all my extensions and try again, but after uninstalling I changed my shortcut > with wich I start Firefox to this: > "D:\Mozilla Firefox\firefox.exe" -UILocale en-US -contentLocale US > > After that, every extension installs perfectly. > > So, the locale must be set for an extension to install properly. Somehow, > there's no default locale or something. Thank you very much for finding that out. I can confirm that invoking Firefox in that fashion definitely fixes the problem (for me). Anyone else who's having problems, try the above workaround.
I can confirm this solves the issues with allinone gesture. I also then added the en-gb locale in the prefs dialogue, and moved it to the top. Now I don't need the extra command line arguments either :-) TabBrowserPreferenes doesn't seem to be on the update site anymore to try it though.
(In reply to comment #56) > TabBrowserPreferenes doesn't seem to be on the update site anymore to try it though. I updated the URL above. TBP v0.5.4 can be had from here: http://www.pryan.org/mozilla/site/TheOneKEA/tabprefs_0.5.4.xpi
URL: http://www.pryan.org/mozilla/site/The... → http://www.pryan.org/mozilla/site/The...
I just get a save/open with dialog when clicking the link...
(In reply to comment #58) > I just get a save/open with dialog when clicking the link... Yes, you will need to save the file to disk. Once saved drag the xpi file to an open Firefox window to install.
Ah ah, OK. Works fine as long as Firefox is started with the extra command line args prior to the drag+drop, otherwise the preferences window for it generators the '<dialog' tag error.
I formated my drive, installed Ff and tried to install TBP and it doesn't work any more. I get XML parsing error. It used to work with the same nightly with clean installation till the format...
(In reply to comment #61) > I formated my drive, installed Ff and tried to install TBP and it doesn't work > any more. I get XML parsing error. It used to work with the same nightly with > clean installation till the format... Does the command-line workaround repair it for you?
(In reply to comment #62) > (In reply to comment #61) > > I formated my drive, installed Ff and tried to install TBP and it doesn't work > > any more. I get XML parsing error. It used to work with the same nightly with > > clean installation till the format... > > Does the command-line workaround repair it for you? It worked for me. I had the same error...
(In reply to comment #63) > > It worked for me. I had the same error... Right, then. I'll add these arguments to the Status Whiteboard so that they don't get lost.
Whiteboard: "-UILocale en-US -contentLocale US": start Firefox once using these to fix the bug
Attached patch patch — — Splinter Review
This should fix almost all cases.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040624 Firefox/0.9.0+ (daihard: P4/SSE2) According to the builder of this build, Ben has already checked in attachment 151578 [details] [diff] [review]. With a totally clean profile, I can install TBP, Web Developer and Bookmarks Synchroniser one right after the other without fault. I believe this bug is RESOLVED FIXED.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Please don't resolve/fix till tested with a ported 0.8 or other profile !
(In reply to comment #67) > Please don't resolve/fix till tested with a ported 0.8 or other profile ! I don't understand - what do you mean?
It wasn't a bug in 'clean' profiles (only) - it affected ported ones.
(In reply to comment #69) > It wasn't a bug in 'clean' profiles (only) - it affected ported ones. In that case, someone should test a 20040624 build with a ported profile. In my experience, the locale errors with clean profiles have been fixed. The patch has been checked into Aviary and FIREFOX_0_9_1_RELEASE anyway, so this bug was going to be closed sooner or later as it were.
We have still the problem with some extension in czech version of the Firefox 0.9.1. E.g.: with Googlebar and Launchy Seems like this wasn't fixed completely.
(In reply to comment #71) > We have still the problem with some extension in czech version of the Firefox 0.9.1. > E.g.: with Googlebar and Launchy > Seems like this wasn't fixed completely. What happens when you use the locale switch workaround, replacing the en-US locale with the cz-CZ locale (or whatever it's called)?
(In reply to comment #72) > What happens when you use the locale switch workaround, replacing the en-US > locale with the cz-CZ locale (or whatever it's called)? Do you mean force firefox.exe -UILocale cs-CZ -contentLocale CZ ? For the Googlebar it helps (what a pity, this step is not suitable for beginne users). But not for the Launchy - the Firefox will not start.
REOPENED. What does the chrome.rdf stanza for the Launchy extension look like, after attempting to force a locale selection using -UILocale cs-CZ -contentLocale CZ?
URL: http://www.pryan.org/mozilla/site/The...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: "-UILocale en-US -contentLocale US": start Firefox once using these to fix the bug → bug is not fixed in 0.9.1 milestone
Is this bug still here in 0.9.2? -R
Mine, more patch coming up
Assignee: bugs → bsmedberg
Status: REOPENED → NEW
This patch should fix a lot of locale and skin switching issues in the chrome registry. The basic idea is to keep a runtime cache of selected packages, rather than saving the selection in RDF. Ben, this needs to get in before beta, because it will be too risky later.
Flags: blocking-aviary1.0PR?
Comment on attachment 155490 [details] [diff] [review] Fix locale- and skin-selection issues in the chrome registry Ben, can you review this or at least rubber-stamp it?
Attachment #155490 - Flags: review?(bugs)
Attachment #155490 - Flags: approval-aviary?
To achieve the effect in the screenshot the following prefs also need to be set this way: dom.disable_window_open_feature.location true dom.disable_window_open_feature.status false
what needs to happen next here?
Whiteboard: bug is not fixed in 0.9.1 milestone → [have patch] bug is not fixed in 0.9.1 milestone
dbaron and brendan will help look at this...
chofmann says in bug 226791 "decision made to turn off dynamic theme switching in an effort to focus on higher priority and more visable areas. dbaron is still looking at issues and is likely to make another run at providing this in a future release." Since the only issues with this patch are the theme-switching, can this be approved?
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0?
Whiteboard: [have patch] bug is not fixed in 0.9.1 milestone → [have patch] - need review ben
Attachment #155490 - Flags: superreview?(brendan)
Comment on attachment 155490 [details] [diff] [review] Fix locale- and skin-selection issues in the chrome registry please don't request approval until you have a fully reviewed patch. thanks.
Attachment #155490 - Flags: approval-aviary?
Whiteboard: [have patch] - need review ben → [have patch] - need review ben bredan
Comment on attachment 155490 [details] [diff] [review] Fix locale- and skin-selection issues in the chrome registry load balance reviewers -> bryner?
Attachment #155490 - Flags: review?(bugs) → review?(bryner)
Comment on attachment 155490 [details] [diff] [review] Fix locale- and skin-selection issues in the chrome registry I don't really know this code, at all. Would be better if someone more familiar with it could review, as this change is not trivial.
Comment on attachment 155490 [details] [diff] [review] Fix locale- and skin-selection issues in the chrome registry >--- chrome/src/nsChromeRegistry.cpp 5 Aug 2004 03:49:22 -0000 1.294.2.1.2.6 >+++ chrome/src/nsChromeRegistry.cpp 8 Aug 2004 18:43:58 -0000 >@@ -238,81 +254,95 @@ nsChromeRegistry::Init() >+ nsCOMPtr<nsIObserverService> observerService = >+ do_GetService("@mozilla.org/observer-service;1", &rv); Here you assign to rv but it's not used for anything, may as well not bother. >+ rv = prefs->AddObserver(SELECTED_SKIN_PREF, this, PR_FALSE); >+ NS_ASSERTION(NS_SUCCEEDED(rv), "Couldn't add skin-switching observer!"); > Hm, here you tell the pref service not to use a weak reference (unlike up above) and you don't remove the observer... won't this create a cycle? >+ prefs->AddObserver(SELECTED_LOCALE_PREF, this, PR_FALSE); Same. >@@ -631,334 +598,192 @@ nsChromeRegistry::GetBaseURL(const nsACS >+nsChromeRegistry::FindProvider(const nsACString& aPackage, const nsACString& aProvider, >+ nsCOMPtr<nsIRDFResource> &aProviderResource, >+ nsCOMPtr<nsIRDFResource> &aPackageResource) .... >+ if (aProvider.Equals(NS_LITERAL_CSTRING("skin"))) { Here you can use EqualsLiteral, on the trunk (but not on the aviary branch). >+ else if (aProvider.Equals(NS_LITERAL_CSTRING("locale"))) { Same. > nsresult >-nsChromeRegistry::InitOverrideJAR() >+nsChromeRegistry::TrySubProvider(const nsACString& aPackage, PRBool aIsLocale, >+ nsIRDFResource* aProviderResource, >+ nsCOMPtr<nsIRDFResource> &aSelectedProvider) > { ... >+ nsCOMPtr<nsIRDFContainer> container >+ (do_CreateInstance("@mozilla.org/rdf/container;1")); >+ NS_ENSURE_TRUE(container, NS_ERROR_UNEXPECTED); NS_ERROR_OUT_OF_MEMORY, or maybe just get the error code from do_CreateInstance? >-// locate > nsresult >-nsChromeRegistry::FindProvider(const nsACString& aPackage, >- const nsACString& aProvider, >- nsIRDFResource *aArc, >- nsIRDFNode **aSelectedProvider) >+nsChromeRegistry::FindSubProvider(const nsACString& aPackage, >+ const nsACString& aProvider, >+ nsCOMPtr<nsIRDFResource> &aSelectedProvider) > { >- *aSelectedProvider = nsnull; >+ nsresult rv; > >- nsCAutoString rootStr("urn:mozilla:"); >- nsresult rv = NS_OK; >+ PRBool isLocale = aProvider.Equals(NS_LITERAL_CSTRING("locale")); Same comment as above about EqualsLiteral. > nsCOMPtr<nsIRDFContainer> container; > rv = nsComponentManager::CreateInstance("@mozilla.org/rdf/container;1", > nsnull, > NS_GET_IID(nsIRDFContainer), > getter_AddRefs(container)); I know this isn't new code, but could this change to use do_CreateInstance? >+ nsXPIDLCString provider; >+ rv = prefs->GetCharPref(pref.get(), getter_Copies(provider)); >+ if (NS_FAILED(rv)) { >+ NS_ERROR("Couldn't get new locale or skin pref!"); >+ return rv; >+ } > >- } >- } >+ if (pref.Equals(NS_LITERAL_CSTRING(SELECTED_SKIN_PREF))) { Same comment about EqualsLiteral. >+ mSelectedSkin = provider; >+ RefreshSkins(); >+ } >+ else if (pref.Equals(NS_LITERAL_CSTRING(SELECTED_LOCALE_PREF))) { and here. r=bryner with those comments addressed.
Attachment #155490 - Flags: review?(bryner) → review+
bryner tells me that this patch puts the selected theme and locale into a pref. How does it handle having partial theme coverage -- e.g., having a theme that doesn't cover some of the extensions you use? Also, I'm not sure that dynamic theme switching will be disabled, and even if it is disabled on the branch, we don't want to break it more on the trunk.
> bryner tells me that this patch puts the selected theme and locale into a pref. > How does it handle having partial theme coverage -- e.g., having a theme that > doesn't cover some of the extensions you use? It uses the selected theme/locale if available, and any other available theme/locale otherwise. > Also, I'm not sure that dynamic theme switching will be disabled, and even if it > is disabled on the branch, we don't want to break it more on the trunk. I need to tweak this patch for the trunk, anyway, so as not to break seamonkey/minimo. I have *no* clue why this patch has any affect on dynamic theme-switching at all, since the RefreshSkins call follows the exact same codepath.
Attachment #155490 - Attachment is obsolete: true
Comment on attachment 157528 [details] [diff] [review] Updated to bryner's review comments, aviary only I tested this patch, and after I updated my tree with bug 252703 all the theme-switching appearances appear normal. I feel fairly confident about this patch now.
Attachment #157528 - Flags: superreview?(brendan)
Attachment #157528 - Flags: review+
Whiteboard: [have patch] - need review ben bredan → [have patch] - need review brendan
Ben checked in code to disable dynamic theme switching based on a pref; this patch is updated with those changes.
Attachment #157528 - Attachment is obsolete: true
Comment on attachment 157770 [details] [diff] [review] updated with latest dss-disablement >- var inUse = cr.isSkinSelected(gCurrentTheme , true); >- if (inUse == Components.interfaces.nsIChromeRegistry.FULL) >- return; >- >- pref.setCharPref(PREF_GENERAL_SKINS_SELECTEDSKIN, gCurrentTheme); > // Set this pref so the user can reset the theme in safe mode > pref.setCharPref(PREF_EM_LAST_SELECTED_SKIN, gCurrentTheme); >+ > if (pref.getBoolPref(PREF_EXTENSIONS_DSS_ENABLED)) { >- cr.selectSkin(gCurrentTheme, true); >- cr.refreshSkins(); >+ pref.setCharPref(PREF_GENERAL_SKINS_SELECTEDSKIN, gCurrentTheme); > } > else { > // Theme change will happen on next startup, this flag tells > // the Theme Manager that it needs to show "This theme will > // be selected after a restart" text in the selected theme > // item. PREF_EXTENSIONS_DSS_ENABLED lets the user turn on dynamic theme switching through about:config if they wish to - this is useful for demos etc. You're replacing the dynamic skin switch calls with a pref setting. So you're now using an observer to observe changes to this setting in CR? (I looked at the patch - I see a call to RefreshSkins in an ::Observe function... just wanted to check that this functionality hadn't broken. sr=ben@mozilla.org and land asap so we can find trouble if it exists.
Attachment #157770 - Flags: superreview+
Attachment #157770 - Flags: approval-aviary+
Fixed on the branch. I'm going to try to merge this onto the trunk and fix up the interfaces to work with seamonkey, there are lots of merge conflicts to resolve.
Keywords: fixed-aviary1.0
Whiteboard: [have patch] - need review brendan → [have patch]
This is the seamonkey-only parts of this patch. Since I removed many methods from nsIXULChromeRegistry which are no longer part of the toolkit but are still needed by seamonkey, these methods are now on a new nsIChromeRegistrySea interface, built only with seamonkey.
Comment on attachment 159545 [details] [diff] [review] Separate seamonkey-only CR methods into a separate interface jst, since this interface is now part of content, you get to do the honors
Attachment #159545 - Flags: superreview?(jst)
Attachment #159545 - Flags: review?(jst)
Comment on attachment 159545 [details] [diff] [review] Separate seamonkey-only CR methods into a separate interface r+sr=jst
Attachment #159545 - Flags: superreview?(jst)
Attachment #159545 - Flags: superreview+
Attachment #159545 - Flags: review?(jst)
Attachment #159545 - Flags: review+
fixed on trunk
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Looks like this fix broke my Win32/MinGW/cygwin build and my Linux (Fedora Core 2 with kernel 2.6.8.1). mozilla/profile/src/nsProfile.cpp has an include of nsIChromeRegistrySea.h which can't be found. This was changed by this patch from nsIChromeRegistry.h. e:/mozilla/source/thunderbird/mozilla/profile/src/nsProfile.cpp:79:34: nsIChrome RegistrySea.h: No such file or directory Reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
d_king, you should be using mail/config/mozconfig which specifies --enable-single-profile
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Hmmm, I don't think I want to know why my builds have worked up to now.
yup, this has broken my Linux builds of *bird: nsProfile.cpp:79:34: nsIChromeRegistrySea.h: No such file or directory re comment 99, what does --enable-single-profile do, exactly? thanks...
Benjamin, perhaps you're already aware of this, but I'm pretty sure your patch of firefox.js on the trunk is causing the string "@AB_CD@" to show up in everyone's buils strings since 20040922. For example, my latest build shows: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; @AB_CD@; rv:1.8a4) Gecko/20040923 Firefox/0.9.1+ It happened at just the right time, anyway: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/browser/app/profile&command=DIFF_FRAMESET&root=/cvsroot&file=firefox.js&rev1=1.25&rev2=1.26
Wayne, thank you, I just committed a supplementary fix on the trunk (I mixed #expand and @substitution@ sytax badly, and didn't add AB_CD to the DEFINES in browser/app/Makefile.in
Comment on attachment 155490 [details] [diff] [review] Fix locale- and skin-selection issues in the chrome registry patch is obsolete
Attachment #155490 - Flags: superreview?(brendan)
Comment on attachment 157528 [details] [diff] [review] Updated to bryner's review comments, aviary only patch is obsolete
Attachment #157528 - Flags: superreview?(brendan)
(In reply to comment #103) > Wayne, thank you, I just committed a supplementary fix on the trunk (I mixed > #expand and @substitution@ sytax badly, and didn't add AB_CD to the DEFINES in > browser/app/Makefile.in Just to document, I opened bug 261492 today on this issue, and then resolved it when I found this bug while researching the regression.
*** Bug 247907 has been marked as a duplicate of this bug. ***
*** Bug 247907 has been marked as a duplicate of this bug. ***
Product: Firefox → Toolkit
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: