I've been reading on what UXP will bring upon release, especially how it's supposed to be a universal platform to develop applications with.However, there's one thing I didn't fully understand: if I were to build my application, would I need to take the whole codebase, change and add the necessary files, release the application and then keep the platform updated on my own, or does it work in the same spirit of (but not equally to) a system library, where my application's users will receive platform updates directly from UXP developers, and application updates from me?Looking at the architecture structure I would think it's the first, but since I don't know anything about either the Mozilla or the UXP codebase, I wanted to ask this.

Full application development.This means you clone the UXP source tree and add your own application in /application/Yourname. You will update the UXP source and build your application as a fully standalone executable. You have full control over what modules and features are included.

Using the XUL runner stub.This is using a minimal application stub that doesn't have any XUL application code itself and is only there to load your XUL application. Usually you build this stub yourself from source with your desired options, but if there is enough demand for this stub then we may release a generic platform build in the future as ready binaries, but building it yourself with your preferred options and optimizations should be trivial. You don't have to integrate the UXP source with your own and can build the stub from a pristine release version of a UXP application, separate from your application development.

Using an existing application with your own application.ini and XUL code.This means you can run your own XUL application code "on top of" an existing UXP application like Basilisk or the future Pale Moon. Your application will depend on what modules and features are included in the "parent" application, so usually you use this for a similar type of application as the parent. You don't have to build UXP yourself and can use ready-made binaries.

Please note that I don't know the current status of the XUL runner stub code at the moment; I've been focusing on full application development (the two browsers) right now.

Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

Current status of xulrunner is the application.ini loader works but has only had casual testing. But any currently existing application on UXP can do that too. Everything else like generating a custom stub is busted.

A few of us WILL fix or rewrite custom stub generation but it is low on the priority list for all of us.

Frankly, it is easier to just structure your own full application if going beyond generic application.ini anyway. Since this is basically what you are doing anyway in addition to the xulrunner stuff.

I hate Pod Six. Tch, I don't even know why we have a Pod Six. Total suck Pod.[ ニュー・トビン・パラダイム ]

Out of curiosity, since the official Mozilla XULRunner hasn't been updated in about a decade, what about UXP broke it?

Also, vannilla, I can tell you that https://developer.mozilla.org/en-US/doc ... /XULRunner is a good place to start looking for XULRunner information and tutorials. I did some fiddling with it a few months back, and if you look, there are some informative docs/tutorials/blog posts.