Closed Bug 328887 (suiterunner) Opened 17 years ago Closed 16 years ago

Turn on the MOZ_XUL_APP flag for SeaMonkey


(SeaMonkey :: Build Config, defect)

Not set


(Not tracked)



(Reporter: standard8, Assigned: kairo)




(Keywords: meta)


(2 files, 1 obsolete file)

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".
OS: Linux → All
Hardware: PC → All
Depends on: 329021
Attached patch xpfe and toolkit main changes. (obsolete) — Splinter Review
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/
> 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).
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.
Depends on: 329742
Depends on: 329744
Depends on: 330053
Depends on: 331758
Blocks: 272429
Depends on: 255807
Depends on: 332203
Attachment #213655 - Attachment is obsolete: true
Depends on: 334478
Alias: suiterunner
No longer depends on: 334478
Depends on: 334478
Depends on: 335154
Depends on: 335739
Depends on: 335800
Depends on: 336874
Depends on: 334997
Depends on: 337636
Depends on: 338461
Depends on: 338880
Depends on: 339022
Depends on: 287945
Depends on: 339837
No longer depends on: 287945
Depends on: 340006
Depends on: 338454
Depends on: 340437
Depends on: 342693
Depends on: 342897
Depends on: 342087
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.
Keywords: meta
Depends on: 343317
Depends on: 343395
Depends on: 343383
Depends on: 344243
Depends on: 344510
Depends on: 346186
Blocks: 346605
Blocks: 306175
Depends on: 348386
Blocks: 349295
Depends on: 349309
Depends on: 350221
Depends on: 351063
Depends on: 351152
Depends on: 351917
Blocks: 351967
Blocks: 56654
Depends on: 359174
Depends on: 324371
Blocks: 111443
Blocks: 207280
Depends on: 361159
Depends on: 361161
Depends on: 361191
Depends on: 361193
Depends on: 361203
Depends on: 361303
Depends on: 361682
Depends on: 361683
Depends on: 361903
Depends on: 362710
Depends on: 363700
Depends on: 364141
Depends on: 364168
Depends on: 348437
Depends on: 365181
Depends on: 366367
Depends on: 366673
Depends on: 366901
Depends on: 370306
Depends on: 370308
Adding bug 370716: "URL bar autocomplete not working on Suiterunner".
Depends on: 370716
Depends on: 350215
Depends on: 371973
Blocks: 372856
Depends on: 373359
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

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.
Depends on: 349409
Depends on: 376912
Depends on: 377185
Depends on: 377953
Depends on: 378279
Depends on: 378545
Depends on: 378647
Depends on: 378743
Blocks: 45701
Blocks: 378913
Depends on: 380347
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.
Assignee: bugzilla → kairo
Attachment #264485 - Flags: superreview?(neil)
Attachment #264485 - Flags: review?(neil)
Attachment #264485 - Flags: superreview?(neil) → superreview+
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.
Attachment #264485 - Flags: review?(neil) → review+
Depends on: 380641
Blocks: 363700
No longer depends on: 363700
Blocks: 380786
Blocks: 336874
No longer depends on: 336874
Blocks: 381159
No longer blocks: 381159
Blocks: 381157
Depends on: 381186
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.
Attachment #265285 - Flags: review?(rhelmer)
Blocks: 381338
Blocks: 381343
Blocks: 278831
Attachment #265285 - Flags: review?(rhelmer) → review+
Depends on: 381483
Blocks: 381780
Depends on: 381915
Depends on: 382168
Blocks: 382187
Depends on: 382243
Depends on: 382245
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.

Closed: 16 years ago
Resolution: --- → FIXED
Blocks: 382425
Blocks: 382500
Blocks: 382449
Blocks: 382585
Blocks: 382586
Blocks: 382795
Blocks: 292075
Depends on: 383252
Depends on: 384712
Blocks: 385056
Blocks: 366673
No longer depends on: 366673
You need to log in before you can comment on or make changes to this bug.