Where did our files go?

[KLB]

I'm using my old chrome.manifest file, I just copied the relevant omni.jar folders to the proper location for my manifest.

[ehume]

Thanks. That should help.

[ehume]

So, after they made us abandon xpi files for jar files, we've now gone back to xpi files?

<Sigh> It's been so many years I've forgotten how do do those.

[ShareBird]

Do they still have a chrome.manifest file?

Yes. Of course.
Inside the omni.jar there is a chrome.manifest file:

Code: Select all

manifest components/interfaces.manifest
manifest components/components.manifest
manifest chrome/nonlocalized.manifest
manifest chrome/localized.manifest

Inside the chrome folder (in omni.jar):
nonlocalized.manifest file:

Code: Select all

# browser.manifest
overlay chrome://browser/content/browser.xul         chrome://browser/content/safebrowsing/report-phishing-overlay.xul
overlay chrome://global/content/viewPartialSource.xul chrome://browser/content/viewSourceOverlay.xul
overlay chrome://browser/content/browser.xul chrome://browser/content/win6BrowserOverlay.xul os=WINNT osversion>=6
overlay chrome://global/content/viewSource.xul chrome://browser/content/viewSourceOverlay.xul
style chrome://global/content/customizeToolbar.xul chrome://browser/content/browser.css
override chrome://global/content/license.html chrome://browser/content/license.html
content branding browser/content/branding/ contentaccessible=yes
skin browser classic/1.0 browser/skin/classic/browser/ os!=WINNT
skin browser classic/1.0 browser/skin/classic/aero/browser/ os=WINNT osversion>=6
content browser browser/content/browser/ contentaccessible=yes
skin browser classic/1.0 browser/skin/classic/browser/ os=WINNT osversion<6
style chrome://global/content/customizeToolbar.xul chrome://browser/skin/
skin communicator classic/1.0 browser/skin/classic/communicator/

# pippki.manifest
content pippki pippki/content/pippki/

# toolkit.manifest
content mozapps toolkit/content/mozapps/
skin global classic/1.0 toolkit/skin/classic/global/ os=WINNT osversion<6
override chrome://global/content/nsTransferable.js chrome://global/content/nsDragAndDrop.js
content satchel toolkit/content/satchel/
content global-region toolkit/content/global-region/
content global toolkit/content/global/ contentaccessible=yes
content global-platform toolkit/content/global-platform/ platform
skin mozapps classic/1.0 toolkit/skin/classic/aero/mozapps/ os=WINNT osversion>=6
skin mozapps classic/1.0 toolkit/skin/classic/mozapps/ os!=WINNT
content passwordmgr toolkit/content/passwordmgr/
skin mozapps classic/1.0 toolkit/skin/classic/mozapps/ os=WINNT osversion<6
skin global classic/1.0 toolkit/skin/classic/aero/global/ os=WINNT osversion>=6
content xbl-marquee toolkit/content/xbl-marquee/
content cookie toolkit/content/cookie/
skin global classic/1.0 toolkit/skin/classic/global/ os!=WINNT

[ShareBird]

So, after they made us abandon xpi files for jar files, we've now gone back to xpi files?

<Sigh> It's been so many years I've forgotten how do do those.

Who said they made us abandon jar files? AFAIK it should be still working...

[ehume]

So, after they made us abandon xpi files for jar files, we've now gone back to xpi files?

<Sigh> It's been so many years I've forgotten how do do those.

Who said they made us abandon jar files? AFAIK it should be still working...

I just took my old {blahblahblah} directory and converted it to a zipfile, then renamed it {blahblahblah}.xpi. My theme went from a non-working disabled extension to an extension I could enable. Now I can see it to work on it.

So far, the worst is the extensions window. Where is that now?

[ehume]

Sorry for the double post.

Now I converted my xpi file back to a directory, and it works now. Squirrely.

[ShareBird]

Did you try to package your theme as jar like you've used to do?

[ehume]

Did you try to package your theme as jar like you've used to do?

Yes. And that works. I guess I shouldn't complain. A non-jarred raw directory now works as well.

Now all I have to do is find out what file controls the Add-on tab. I've replaced my own file with the cssfile from the recent release. Makes no difference.

Oh well, it's not as bad as I thought it would be. Whatever change they made to the app tab fixed that problem.

[KLB]

So, after they made us abandon xpi files for jar files, we've now gone back to xpi files?

<Sigh> It's been so many years I've forgotten how do do those.

Why do you think we have to use XPI files for themes?
I'm still using a jar file for my theme.

[ehume]

So, after they made us abandon xpi files for jar files, we've now gone back to xpi files?

<Sigh> It's been so many years I've forgotten how do do those.

Why do you think we have to use XPI files for themes?
I'm still using a jar file for my theme.

I think we don't. Firefox4 just choked on mine for a while.

[CatThief]

@ehume -- Firefox takes the jar and creates the {blah-blah}.xpi. Nothing on your end changes. Just pack everything into a single jar just like before. The structure will be a bit different since you no longer need the jar inside a jar, but that's all.

What is most helpful is if you set the pref "extensions.alwaysUnpack" to "true", then extension sub-directories will be created the same way they were before and you can just directly edit the existing files of the installed theme. By unpacking them the performance hit is ever so slight, yet it's worth it for such easy accessibility.

[ehume]

@ehume -- Firefox takes the jar and creates the {blah-blah}.xpi. Nothing on your end changes. Just pack everything into a single jar just like before. The structure will be a bit different since you no longer need the jar inside a jar, but that's all.

What is most helpful is if you set the pref "extensions.alwaysUnpack" to "true", then extension sub-directories will be created the same way they were before and you can just directly edit the existing files of the installed theme. By unpacking them the performance hit is ever so slight, yet it's worth it for such easy accessibility.

Wonderful trick. Thank you.

[ShareBird]

@ehume -- Firefox takes the jar and creates the {blah-blah}.xpi. Nothing on your end changes. Just pack everything into a single jar just like before. The structure will be a bit different since you no longer need the jar inside a jar, but that's all.

What is most helpful is if you set the pref "extensions.alwaysUnpack" to "true", then extension sub-directories will be created the same way they were before and you can just directly edit the existing files of the installed theme. By unpacking them the performance hit is ever so slight, yet it's worth it for such easy accessibility.

While this could be very interesting for you as developer, it will impact the performance at the user side... (I've just tested it on my computer. If I install my theme as compressed file, Firefox starts really fast, in opposite as the profiles where I use to work with uncompressed files)

I don't know how you guys and girls are setting your workflow up, but I use to develop my themes an uncompressed installation on my profile. In this way I can see the modifications quite at "real time" (using the reload chrome function from my extension Switch Themes).
when I release a version (dev or release) I just use a simple bat file to compress the whole theme as I wish.

[ehume]

" . . . from my extension Switch Themes"

And where might one get that? (he asks so sweetly . . .)