Closed
Bug 242198
Opened 20 years ago
Closed 20 years ago
Javascript component not loaded if profile manager is bypassed
Categories
(Core :: XPConnect, defect)
Core
XPConnect
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: raj, Assigned: dbradley)
Details
Attachments
(1 file)
5.90 KB,
text/plain
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040427 MultiZilla/1.6.3.2d Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040427 MultiZilla/1.6.3.2d The MultiZilla extension uses its own Javascript component (mzContentBlocker.js). This does not get loaded if I use the "don't ask on startup" option in the profile manager to load my profile. If I go through the profile manager to get to my profile, the component is loaded (as shown by output on the console (by running Mozilla with the -console argument) Reproducible: Always Steps to Reproduce: 1. Set Mozilla to use a profile by default (ie select one from the profile manager and select "don't ask on startup". 2. Restart Mozilla and install MultiZilla -- http://multizilla.mozdev.org/installation.html 3. Restart Mozilla with the console enabled to see output of the component's dump() lines Actual Results: Component is not loaded Expected Results: Component should be loaded If you go back to the profile manager and untick "don't ask at startup", then the component is loaded next time that you restart (I did this several times and got consistant results) PS: I'm not sure about the component, but did a search for other bugs with "component load" in the summary and this seemed to be best one; sorry if it was wrong.
The "Don't ask at startup" checkbox sets 'startWithLastUsedProfile' true. See also: http://lxr.mozilla.org/seamonkey/source/profile/resources/content/profileSelection.js#244 http://lxr.mozilla.org/seamonkey/source/profile/public/nsIProfileInternal.idl#127 Looks like the profile manager is doing some extra work at startup...
Status: UNCONFIRMED → NEW
Ever confirmed: true
I took another closer look and checked boolean isCIDRegistered(in nsCIDRef aClass); and boolean isContractIDRegistered(in string aContractID); and both of them return |true| Seems alright, however, string getCategoryEntry(in string aCategory, in string aEntry); returns "" and that can't be right is it?
(In reply to comment #2) > string getCategoryEntry(in string aCategory, in string aEntry); > returns "" and that can't be right is it? Nope, that is right, because this was used to add the category: this.getCategoryManager().addCategoryEntry("content-policy", this.mContractID, "", true, true); Is "" allowed for aValue or not?
Darn, this bug report is almost six months old now, and there's still not even a single comment/reaction to it. This is a very serious problem for MultiZilla. Anyone?
Interesting. I took another look and I think I found something because its this line that fails without the profile manager: addPrefListener(cbPrefListener); Btw, here's a snip of the prefListener const cbPrefListener = { domain: "multizilla", observe: function(subject, topic, aPrefName) { ... }
Assignee | ||
Comment 7•20 years ago
|
||
Can you give a little explanation as to why you marked this bug as such? Just in case someone happens to go down the same road as you and happens to find this bug.
1) add the prefs for this component (see component) 2) delete compreg.dat 3) restart mozilla (compreg.dat will be recreated) 4) quit mozilla 5) restart mozilla with -console Now, check the output on your console. I have also included the lines I got on my console (WinXP) and I am interested in getting any input back, without having to wait another 6 months or so.
Comment 10•20 years ago
|
||
Oops, please note that you should check with and without the profile manager displayed at startup! In short, the profile manager triggers the pref listener, but I am unable to trace that back to the mozilla source. Can you please help me with that? My component gets 'loaded' but the pref listener isn't triggered, so I simply made a work around for this problem ;)
You need to log in
before you can comment on or make changes to this bug.
Description
•