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)

x86
All
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: kakadu+bugzilla, Assigned: benjamin)

References

Details

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

Attachments

(6 files, 2 obsolete files)

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
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 patchSplinter 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?
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 ago20 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 ago20 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

Created:
Updated:
Size: