Wrong regChrome switch still registers content.rdf chrome



Core Graveyard
Installer: XPInstall Engine
17 years ago
2 years ago


(Reporter: David Epstein, Assigned: dveditz)


Firefox Tracking Flags

(Not tracked)





17 years ago
builds 2001-01-09-04 branch.
1. Go to http://jimbob/trigger3.html
2. Enter http://jimbob/jars/f_reg_chrm_3_err_switch.xpi in the URL field. Script  
contains registerChrome() pointing to contents.rdf contents (3rd parameter is 
"contents/chatzilla" but 1st parameter uses SKIN switch)
3. Press Trigger. Then OK.
4. Check logfile.
Result: registerChrome returns 0.
Expected: registerChrome returns -239 error. Uses incorrect switch.

Comment 1

17 years ago
reassigned to depstein. Here's the logfile contents:

   functional: f_reg_chrm_3_err_switch

     ** returned getfolder = C:\Program Files\Netscape\Netscape 6\chrome\
     ** addFile returns = 0
     [1/1]	Replacing: C:\Program Files\Netscape\Netscape 

     Install completed successfully
     The regChrome() part

     ** regChrome (SKIN) of content/chatzilla should return -239 = 0
     [1/1]	Register Skin: resource:/chrome/content/chatzilla/

and the script:

var regNode = "f_reg_chrm_3_err_switch";
var vi = "";
var jarSrc = "chatzilla.jar";

initInstall("functional: f_reg_chrm_3_err_switch", regNode, vi, 0);

f = getFolder("Chrome");
logComment("returned getfolder = " + f);
err = addFile(regNode, jarSrc, f, jarSrc);
logComment("addFile returns = " + err);


initInstall("The regChrome() part", regNode, vi, 0);

err = registerChrome(SKIN, f, "content/chatzilla/"); 
logComment("regChrome (SKIN) of content/chatzilla should return -239 = " + err);


function PerformOrCancel()
   if (0 == getLastError())
QA Contact: jimmylee → depstein

Comment 2

17 years ago
reassigning to dveditz.  He's the register chrome guru.
Assignee: dbragg → dveditz

Comment 3

17 years ago
There's not much we can do about this one. This isn't technically an error as 
far as the chrome registry is concerned, you gave it an rdf file and told it to 
process any SKIN entries, and it successfully processed all the ones it found 
(none) so it doesn't report any errors.

I'm not sure why the Chrome Registry doesn't just process all of a contents.rdf 
file (and then we wouldn't specify which type at all), but given the 
flexibility built into the system this is just something script authors will 
have to figure out.

One alternative design would be to eliminate the first type argument and always 
pass all three types to the chrome registry for every .rdf file. This would be 
somewhat slow due to extra registration processing.
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 4

17 years ago
In this case, there are 3 contents.rdf files (in chatzilla.jar). One points to 
contents, another to skins, and the 3rd to locales. Each has a separate local 
pathway (e.g. "contents/chatzilla/") passed as 3rd parameter. Shouldn't we 
return an error if we point regChrome() to one of these, while using the wrong 

Comment 5

17 years ago
The fact that the contents.rdf are split along chrome-type lines is merely a 
convention. Any manifest.rdf/contents.rdf could potentially contain any of the 
three types or a mixture of all three and the chrome registry doesn't know or 
care, it will just process what you tell it.

The chrome registry isn't going to know that a type you specified isn't in the 
manifest until it parses it at performInstall() time, and I don't want to 
return an error at that point which would abort the rest of the install (plus, 
the chrome folks obviously don't consider it an error so we'd have to 
convince them to change this).

I just don't see the benefit from convincing the already overloaded and 
behind-schedule XUL guy(s) to fix this, thus WONTFIX (as opposed to INVALID -- 
I see your point).

Comment 6

17 years ago
OK, fair enough!
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.