Enabling MOZ_XUL_APP is part of the SeaMonkey transition to toolkit plan. This bug will be used to handle the enabling of MOZ_XUL_APP for SeaMonkey. As Kairo says: - This will get us lots of the new infrastructure, but we don't know yet what will break in what way.

You should look in particular for MOZ_THUNDERBIRD ifdefs in mailnews/, most or all of which should be turned into MOZ_XUL_APP ifdefs.

In some cases, |ifndef MOZ_XUL_APP| might be used for testing suite-specific state right now, those should be changed to |ifdef MOZ_SUITE| where applicable. There are also things we'll need to sort out where it might be a good idea to do step-by-step migration to the new code and not do everything with flipping that one switch right now. Maybe we should add some temporary MOZ_SUITE switches there with some comments saying "XXX: temporary switch for SeaMonkey transition", using the same comment everywhere we do it so an LXR search for it is easy. Our current goal is to get patches into trunk to get a basically working SeaMonkey with MOZ_XUL_APP=1 and when those patches are in, we'll flip that switch in trunk as well. That will make us not break official nightlies while figuring out what changes underneath us with that step. We should try to keep the time of still building the "old world" while working on the "new world" as short as possible though while still retaining the look and feel of the suite also in the "new world".

These are the initial main makefile changes for xpfe and toolkit. It won't compile with these, and I'm not going to submit this patch for review - it needs more work before then. As discussed with KaiRo & others on IRC, we're trying to keep the changes from xpfe -> toolkit minimal to being with. Hence at the moment I'm only picking up the startup and commandlines components from toolkit, replacing startup from xpfe as that seemed the most logical. I'll add in new items as I progress. Comments are welcome. Bear in mind this is WIP.

Comment on attachment 213655 [details] [diff] [review] xpfe and toolkit main changes. >Index: xpfe/components/Makefile.in >=================================================================== >-ifdef MOZ_HAVE_BROWSER > DIRS += alerts prefwindow >-endif This looks wrong to me, I think the DIRS line itself should be removed as well, as from what I saw, this should actually never be built/added right now, being |ifdef MOZ_HAVE_BROWSER| inside a |ifndef MOZ_HAVE_BROWSER| block... Additionally, please be sure to add some "XXX" comments everywhere you add ifdefs that are temporary (i.e. will disappear once we do a full migration to all the "toolkit"/xulrunner framework).

I don't think it will work to use the toolkit startup/commandline code without switching from xpfe/boostrap to toolkit/xre. I think you need to decide whether you're going to switch over to the toolkit bootstrap mechanism first or last in this process; (and if you're going to switch over first, it would be pretty simple to switch to use xulrunner directly right away).

Having spent some time experimenting with different approaches. We have come to the conclusion that this would be the best way forward: Initially we switch from the xpfe bootstrap to toolkit version, this would need to pick up the following items as a minimum from toolkit - startup - profile - extension manager - chrome registry - commandlines This will mean SeaMonkey looses a few features, like Switch Profile and possibly quick launch. However we'd probably have to re-implement them at some stage anyway if we wanted to keep them, and its not to say that we won't re-implement them. Additionally, for this initial switch, the most sensible thing to do seems to be to use toolkit/xre as the startup mechanism, to keep the changes to a minimum. If we start using xulrunner, we're going to have to do more xpfe->toolkit transitions/extensions at the start. That's not to say we're going to delay transition to xulrunner for a long time, its still on the priority list for as soon as it is sensible, but in the very short term we need to get something running with MOZ_XUL_APP=1 such that we can start finding any problems asap.

Judging by the "depends-on" bug names, it seems some of them relate more to making sm a xulrunner app rather than just turning on MOZ_XUL_APP. If this is true, someone please review which dependencies are genuine in this respect.

(In reply to comment #7) > Judging by the "depends-on" bug names, it seems some of them relate more to > making sm a xulrunner app rather than just turning on MOZ_XUL_APP. If this is > true, someone please review which dependencies are genuine in this respect. > The only bug for which this may be true is bug 336874. However I'm not going to remove it from the dependency list as the work being done on it may still be beneficial to turning on MOZ_XUL_APP. This is a tracking bug but remember that although a bug is on the dependency list we may still choose to turn on MOZ_XUL_APP before it is completed - but we need to know all the bugs to make that an informed decision.

Adding bug 370716: "URL bar autocomplete not working on Suiterunner".

Shall we flip the switch once we have the tabbrowser working with toolkit <browser>?

Which switch would that be? Push suiterunner builds as the default nightly builds? At a minimum we should wait for bug 329744, right? A more conservative switch might be to push the builds to nightly/ with an extra suffix to identify it as a suiterunner build. Unfortunately, we lack a linux tinderbox here, (hoshi probably doesn't even have the libs to build trunk). Anyway, we could do that and actively seek people to try using the builds (as opposed to the current "hey these builds are in exp/, they're kinda broken") and report bugs.

(In reply to comment #11) > Which switch would that be? Push suiterunner builds as the default nightly > builds? At a minimum we should wait for bug 329744, right? Yes, because otherwise folks won't be able to upgrade/migrate to the new profile. We should probably also take a look at http://wiki.mozilla.org/SeaMonkey:suiterunner#Bug_state I think bug 348386 - download manager not working is a definite blocker for the switch as well. The NSIS installer for Windows (bug 359179) is also a possibility - though we could ship just zip builds for windows for the time being. Also, we should really push for a fix on bug 338461 - File->New Navigator Window (which also affects Window->Navigator) as that'll be quite annoying for some people as well.

Here's the final patch for doing the real switch on trunk. Taking the bug as I am doing this one patch to switch us over. The SeaMonkey Council also agreed to switch the version number at the same time, so the point will be clearly marked and toolkit-based nightlies will be easy to distinguish from their precedessors. Note that the patch is ready, but the tree is not ready yet for it being checked in, we will still wait for some dependencies to be resolved: We still need to get bug 348386 fixed as a strict requirement to get this patch checked in, bug 329744 and bug 351917 are things we also would like to have until then - the rest of the open dependencies are no real blockers, just things somehow connected with this bug, as we're using this as a kind of tracker of suiterunner fixes as well.

Comment on attachment 264485 [details] [diff] [review] build suiterunner by default and bump the SeaMonkey version Note that all depend builds will have to clobber in mailnews/ to pick up the static mail build change correctly.

We need to update $VendorName and $package_creation_path in the configs of our tinderboxen along with that switch to suiterunner - and make sure we only build the installers we actually have.

Both patches have landed, along with clobbering our Dep tinderboxes, so we can be sure only new code is picked up there now. I hope everything goes well with that, so marking FIXED. yay!