Closed Bug 242198 Opened 20 years ago Closed 20 years ago

Javascript component not loaded if profile manager is bypassed

Categories

(Core :: XPConnect, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: raj, Assigned: dbradley)

Details

Attachments

(1 file)

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?
OS: Windows 2000 → All
Hardware: PC → All
(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) {
  ...
}
.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: