doesn't work on latest xulrunner from trunk

[lloyd]

We should understand and fix whatever is preventing code from working on latest xulrunner nightlies.

[lloyd]

I have some early success with running under latest xulrunner in the experimental_latest_xulrunner branch. The core problem and a proposed solution is summarized in this email excerpt:

I'm working to make chromeless run on top of the latest trunk, which is xulrunner 2.0bX. As far as I understand, significant changes in component registration have removed the entry point we used to rely on.

That is, previously it was sufficient to drop a .js file in the components/ directory, and that component would be evaluated as part of application startup. This was harness.js. Also, if I understand correctly, bootstrap.js was used in the extension case in 1.9.3+ as an entry point.

So in short, the symptom I'm seeing is that xulrunner 2.0 invoked with arguments to run a (slightly modified version of cuddlefish lab) starts up, but doesn't actually render a window. xulrunner 1.9.2.10 evaluates harness.js (but not bootstrap.js) and works as advertised.

My thought was to address this I can move the code inside harness.js into chrome/content, and add a xul file containing an invisible window to include that initial bit of javascript and get things started.

Given that I don't think we care about compatibility with previous versions of xulrunner, and we don't really care that any of this code runs inside any context other than that of xulrunner, does my understanding and approach seem right here?

[taboca]

We need to check if we could synchronize here work with the Jetpack SDK work, for XULRunner compatibility, before we launch a chrome-based window. Launching a more traditional chrome-based app indeed works. But if we could keep a main.js being executed, we would be possible to expose this initial main.js as being the script before index.html execution ( make it simple and expose it to the developer ). In other words, would follow the harness/cuddlefish architecture, this would allow developer to , let's say if they wanted, make even a total windowless app - execute JS and eventually launch window(s).

Other problem I saw with the case we have, is that I saw the 0x0 window with Mac OS X. So when launching the chromeless app I see a very tiny window at the 0x0 position of the screen with a 1xY size.

Jetpack + Chromeless Friendly bug - I am hoping Atul could help us out here.

https://bugzilla.mozilla.org/show_bug.cgi?id=608419

[lloyd]

atul closed out the above bug as a dup of this one: https://bugzilla.mozilla.org/show_bug.cgi?id=593493

of the three options atul proposes, the "fake" xul window approach is one of them, and this is the approach we're currently utilizing.

Marcio, do you have any problem with me making the -chrome template the default and closing out this issue?

[lloyd]

issue addressed in current trunk. I agree with marcio that we should seek a cleaner solution (no xul window is desired, just a hook at xul startup where we can evaluate our bootstrapping javscript), and will open a separate bug for that.