Closed Bug 162960 Opened 18 years ago Closed 17 years ago
chrome registry doesn't enumerate overlays installed in user profile
2.17 KB, application/x-xpinstall
2.13 KB, patch
|Details | Diff | Splinter Review|
2.17 KB, application/x-xpinstall
This bug involves installing XPIs with overlays into the profile folder. In contrast to Bug 125610, I find that it *is* possible to install the XPI into my profile folder and an "overlayinfo" directory is indeed created. However, when mozilla restarts, the overlay is not loaded... nsOverlayEnumerator::GetNext() only enumerates overlays from the installed directory and not the user's profile.
This patch fixes the problem for me... I'm able to install XPIs with overlays into my user profile and load them when mozilla restarts. I assumed that installed overlays should be enumerated before the profile overlays, but if the reverse is true, then mCurrentArcs should probably be initialized to mProfileArcs instead of mInstallArcs in the constructor.
Hmm... According to Bug 160354, RDF is orphaned. I'm really not sure where bugs relating to nsChromeRegistry belong. Skinability? XP Apps? XUL? Help!
Assignee: waterson → sgehani
Component: RDF → XP Apps
OS: Linux → All
QA Contact: tever → paw
Hardware: PC → All
I hope this helps the QA people: The installer should create a new task button in the task bar (next to the ChatZilla icon in the lower left corner). Without the patch, the overlay isn't loaded, and the mozilla icon doesn't appear. After applying the patch, the mozilla icon appears as expected, and clicking on it pops up an alert box containing "Test case for Bug 162960".
Forgot to mention that you should restart the browser after installing the XPI... I'd like to get this into 1.0.1 if possible, so if someone could verify the bug and the patch, I would very much appreciate it!!!
Thanks for the patch! I'll play with it.
Assignee: sgehani → dveditz
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla1.2beta
Did the patch get applied? I've tested the example xpi (attachment 97262 [details]) with both 1.3b (2003021008) and 1.0.2 (2002121607). In both cases: * The xpi creates the overlays correctly in the profile directory. * On restart, the icon doesn't show in the component bar. * However, strace shows that Moz did read the overlay. * The chrome has been registered correctly. (I can go to chrome://bug162960/content/bugzilla-16.png and see the icon.) I'd guess from this that the patch didn't make it. What's happening?
Comment on attachment 95489 [details] [diff] [review] enumerate overlays from user profile folder dave, dan, can you guys see if this is any good. If so, it would be great to get this in early in 1.4 and let the extensions developers get started making mods and alterations.
Note that the only way to get hyatt to review is to mail him in person -- he does not read bugmail and does not look at his review queue...
Assignee: dveditz → peterv
Priority: -- → P2
Target Milestone: mozilla1.2beta → mozilla1.4alpha
Comment on attachment 116228 [details] [diff] [review] First check profile, then install sr=hyatt
Attachment #116228 - Flags: superreview?(hyatt) → superreview+
Comment on attachment 116228 [details] [diff] [review] First check profile, then install looks good and works great r=varga
Attachment #116228 - Flags: review?(varga) → review+
Yet more *%$# overlay directories? :-/
Neil, I think it was already supposed to work in both directories, this is just a bug not new feature
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
It's either have the overlay directories in your profile, or have to re-install add-ons each time you upgrade Mozilla.
What happens when someone installed an add-on in his mozilla/chrome directory and later updates the smae add-on in his profile/chrome?
extension writers could do with a template install.js to enable this i.e. give user option to install locally/globally, also checking that their build is capable of local installation
Comment on attachment 95489 [details] [diff] [review] enumerate overlays from user profile folder removing obsolete review requests
You need to log in before you can comment on or make changes to this bug.