2

I recently took on a project built on XUL (standalone, using xulrunner) - However I can't get it to properly run. I'm getting this error when I attempt to start it using the command line (xulrunner.exe ../application.ini -jsconsole):

No chrome package registered for chrome://case_scenario_builder/content/case_scenario_builder.xul

The chrome.manifest file looks like this:

content case_scenario_builder file:chrome/case_scenario_builder/content/ contentaccessible=yes
content jslib jar:chrome/jslib.jar!/ 
skin case_scenario_builder skin file:chrome/case_scenario_builder/skin/
locale case_scenario_builder en-US chrome/case_scenario_builder/locale/en-US/

Any ideas on where I could start debugging?

ThinkingStiff
  • 64,767
  • 30
  • 146
  • 239
Fjell Maxim
  • 98
  • 6

3 Answers3

2

I figured it out! In case anyone else runs into this as well: It was due to the caching system in place by default and the use of .jar containers instead of folders. The XUL environment had cached both JS and XUL files - and even after disabling those, I had to extract everything that was in the .jar file to the content folder and update the chrome.manifest file.

Thanks for your suggestions on debugging! - they helped the process.

Fjell Maxim
  • 98
  • 6
1

I guess your manifest just isn't getting loaded. To test that I'd introduce an intentional syntax error and check the error console. E.g. if you put 

asdfasd

on its own line, you should get a Warning: Ignoring unrecognized chrome manifest directive 'asdfasd'. in the Error console.

(Note to other experts: initially I wanted to suggest dropping 'file:' prefix and avoiding underscores in the package name, but I tested it on a Firefox nightly, and it works fine.)

Nickolay
  • 31,095
  • 13
  • 107
  • 185
0

Your chrome package clearly didn't get registered. From what I can tell, the reason is the bogus file: prefix, you should drop it when specifying relative paths:

content case_scenario_builder chrome/case_scenario_builder/content/ contentaccessible=yes

Btw, I suspect that you copied contentaccessible=yes from somewhere - you should drop it as well unless you know what it does.

Wladimir Palant
  • 56,865
  • 12
  • 98
  • 126
  • That was my first idea too, but specifying a relative URL with the `file:` prefix worked in my testing... – Nickolay Mar 07 '12 at 21:58
  • Wow, I knew that the manifest parser had some strange special handling for `jar:` URLs but apparently it does something to `file:` URLs as well - didn't know that :) – Wladimir Palant Mar 07 '12 at 22:09