Last Comment Bug 328887 - (suiterunner) Turn on the MOZ_XUL_APP flag for SeaMonkey
: Turn on the MOZ_XUL_APP flag for SeaMonkey
: meta
Product: SeaMonkey
Classification: Client Software
Component: Build Config (show other bugs)
: Trunk
: All All
-- normal with 7 votes (vote)
: ---
Assigned To: Robert Kaiser
Depends on: 255807 324371 329021 329742 329744 330053 331758 332203 334478 334997 335154 335739 335800 337636 338454 338461 338880 339022 339837 340006 340437 342087 342693 342897 343317 343383 343395 344243 344510 346186 348386 348437 349309 349409 350215 350221 351063 351152 351917 359174 361159 361161 361191 361193 361203 361303 361682 361683 361903 362710 364141 364168 365181 366367 366901 370306 370308 370716 371973 373359 376912 377185 377953 378279 378545 378647 378743 380347 380641 381186 381483 381915 382168 382243 382245 383252 384712
Blocks: 45701 56654 111443 207280 272429 278831 292075 306175 336874 346605 349295 351967 363700 366673 372856 378913 380786 381157 381338 381343 381780 382187 382425 382449 382500 382585 382586 382795 383052 385056
  Show dependency treegraph
Reported: 2006-02-28 12:58 PST by Mark Banner (:standard8)
Modified: 2017-02-23 08:10 PST (History)
52 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

xpfe and toolkit main changes. (10.59 KB, patch)
2006-03-01 14:03 PST, Mark Banner (:standard8)
no flags Details | Diff | Splinter Review
build suiterunner by default and bump the SeaMonkey version (2.51 KB, patch)
2007-05-11 09:43 PDT, Robert Kaiser
neil: review+
neil: superreview+
Details | Diff | Splinter Review
tinder-config changes needed along with that switch (7.73 KB, patch)
2007-05-18 11:41 PDT, Robert Kaiser
rhelmer: review+
Details | Diff | Splinter Review

Description User image Mark Banner (:standard8) 2006-02-28 12:58:32 PST
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.
Comment 1 User image Benjamin Smedberg [:bsmedberg] 2006-02-28 13:00:23 PST
You should look in particular for MOZ_THUNDERBIRD ifdefs in mailnews/, most or all of which should be turned into MOZ_XUL_APP ifdefs.
Comment 2 User image Robert Kaiser 2006-02-28 17:39:31 PST
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".
Comment 3 User image Mark Banner (:standard8) 2006-03-01 14:03:38 PST
Created attachment 213655 [details] [diff] [review]
xpfe and toolkit main changes.

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 4 User image Robert Kaiser 2006-03-01 15:06:47 PST
Comment on attachment 213655 [details] [diff] [review]
xpfe and toolkit main changes.

>Index: xpfe/components/
> DIRS  += alerts prefwindow

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).
Comment 5 User image Benjamin Smedberg [:bsmedberg] 2006-03-02 05:40:55 PST
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).
Comment 6 User image Mark Banner (:standard8) 2006-03-07 12:42:27 PST
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.
Comment 7 User image Eyal Rozenberg 2006-06-30 22:36:18 PDT
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.
Comment 8 User image Mark Banner (:standard8) 2006-07-01 00:19:27 PDT
(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.
Comment 9 User image Caio Tiago Oliveira (asrail) 2007-02-16 20:15:04 PST
Adding bug 370716: "URL bar autocomplete not working on Suiterunner".
Comment 10 User image Chris Thomas (CTho) [formerly] 2007-03-31 19:39:50 PDT
Shall we flip the switch once we have the tabbrowser working with toolkit <browser>?
Comment 11 User image Andrew Schultz 2007-03-31 19:58:23 PDT
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.
Comment 12 User image Mark Banner (:standard8) 2007-04-01 03:51:16 PDT
(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

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.
Comment 13 User image Robert Kaiser 2007-05-11 09:43:39 PDT
Created attachment 264485 [details] [diff] [review]
build suiterunner by default and bump the SeaMonkey version

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 14 User image 2007-05-13 09:54:21 PDT
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.
Comment 15 User image Robert Kaiser 2007-05-18 11:41:17 PDT
Created attachment 265285 [details] [diff] [review]
tinder-config changes needed along with that switch

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.
Comment 16 User image Robert Kaiser 2007-05-29 10:02:57 PDT
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.


Note You need to log in before you can comment on or make changes to this bug.