Bug 328887 (suiterunner)

Turn on the MOZ_XUL_APP flag for SeaMonkey

RESOLVED FIXED

Status

defect
RESOLVED FIXED
13 years ago
6 months ago

People

(Reporter: standard8, Assigned: kairo)

Tracking

({meta})

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

13 years ago
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

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

Comment 2

13 years ago
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".
Reporter

Updated

13 years ago
OS: Linux → All
Hardware: PC → All
Reporter

Updated

13 years ago
Depends on: 329021
Reporter

Comment 3

13 years ago
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.
Assignee

Comment 4

13 years ago
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).

Comment 5

13 years ago
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).
Reporter

Comment 6

13 years ago
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.
Reporter

Updated

13 years ago
Depends on: 329742
Reporter

Updated

13 years ago
Depends on: 329744
Reporter

Updated

13 years ago
Depends on: 330053
Reporter

Updated

13 years ago
Depends on: 331758
Reporter

Updated

13 years ago
Blocks: 272429
Depends on: 255807
Reporter

Updated

13 years ago
Depends on: 332203
Reporter

Updated

13 years ago
Attachment #213655 - Attachment is obsolete: true
Assignee

Updated

13 years ago
Depends on: 334478
Assignee

Updated

13 years ago
Alias: suiterunner
No longer depends on: 334478
Assignee

Updated

13 years ago
Depends on: 334478
Reporter

Updated

13 years ago
Depends on: 335154
Assignee

Updated

13 years ago
Depends on: 335739

Updated

13 years ago
Depends on: 335800
Assignee

Updated

13 years ago
Depends on: 336874
Assignee

Updated

13 years ago
Depends on: 334997
Reporter

Updated

13 years ago
Depends on: 337636
Reporter

Updated

13 years ago
Depends on: 338461

Updated

13 years ago
Depends on: 338880
Reporter

Updated

13 years ago
Depends on: 339022

Updated

13 years ago
Depends on: 287945

Updated

13 years ago
Depends on: 339837

Updated

13 years ago
No longer depends on: 287945
Reporter

Updated

13 years ago
Depends on: 340006

Updated

13 years ago
Depends on: 338454
Assignee

Updated

13 years ago
Depends on: 340437
Assignee

Updated

13 years ago
Depends on: 342693
Reporter

Updated

13 years ago
Depends on: 342897
Assignee

Updated

13 years ago
Depends on: 342087

Comment 7

13 years ago
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.
Reporter

Comment 8

13 years ago
(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
Reporter

Updated

13 years ago
Depends on: 343317
Reporter

Updated

13 years ago
Depends on: 343395
Reporter

Updated

13 years ago
Depends on: 343383
Assignee

Updated

13 years ago
Depends on: 344243
Reporter

Updated

13 years ago
Depends on: 344510
Assignee

Updated

13 years ago
Depends on: 346186
Assignee

Updated

13 years ago
Blocks: 346605
Reporter

Updated

13 years ago
Blocks: 306175
Reporter

Updated

13 years ago
Depends on: 348386
Reporter

Updated

13 years ago
Blocks: 349295
Reporter

Updated

13 years ago
Depends on: 349309
Assignee

Updated

13 years ago
Depends on: 350221
Reporter

Updated

13 years ago
Depends on: 351063
Reporter

Updated

13 years ago
Depends on: 351152
Depends on: 351917
Assignee

Updated

13 years ago
Blocks: 351967

Updated

13 years ago
Blocks: 56654
Assignee

Updated

13 years ago
Depends on: 359174
Assignee

Updated

13 years ago
Depends on: 324371
Reporter

Updated

13 years ago
Blocks: 111443
Reporter

Updated

13 years ago
Blocks: 207280
Reporter

Updated

13 years ago
Depends on: 361159
Reporter

Updated

13 years ago
Depends on: 361161
Reporter

Updated

13 years ago
Depends on: 361191
Reporter

Updated

13 years ago
Depends on: 361193
Reporter

Updated

13 years ago
Depends on: 361203
Reporter

Updated

13 years ago
Depends on: 361303
Reporter

Updated

13 years ago
Depends on: 361682
Reporter

Updated

13 years ago
Depends on: 361683

Updated

13 years ago
Depends on: 361903
Reporter

Updated

13 years ago
Depends on: 362710
Reporter

Updated

13 years ago
Depends on: 363700

Updated

13 years ago
Depends on: 364141
Reporter

Updated

13 years ago
Depends on: 364168
Reporter

Updated

13 years ago
Depends on: 348437

Updated

13 years ago
Depends on: 365181
Reporter

Updated

13 years ago
Depends on: 366367
Reporter

Updated

13 years ago
Depends on: 366673
Reporter

Updated

13 years ago
Depends on: 366901
Reporter

Updated

12 years ago
Depends on: 370306
Reporter

Updated

12 years ago
Depends on: 370308
Adding bug 370716: "URL bar autocomplete not working on Suiterunner".
Depends on: 370716
Reporter

Updated

12 years ago
Depends on: 350215

Updated

12 years ago
Depends on: 371973
Reporter

Updated

12 years ago
Blocks: 372856

Updated

12 years ago
Depends on: 373359
Shall we flip the switch once we have the tabbrowser working with toolkit <browser>?

Comment 11

12 years ago
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.
Reporter

Comment 12

12 years ago
(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.

Updated

12 years ago
Depends on: 349409

Updated

12 years ago
Depends on: 376912
Reporter

Updated

12 years ago
Depends on: 377185
Assignee

Updated

12 years ago
Depends on: 377953

Updated

12 years ago
Depends on: 378279

Updated

12 years ago
Depends on: 378545
Reporter

Updated

12 years ago
Depends on: 378647

Updated

12 years ago
Depends on: 378743

Updated

12 years ago
Blocks: 45701

Updated

12 years ago
Blocks: 378913
Assignee

Updated

12 years ago
Depends on: 380347
Assignee

Comment 13

12 years ago
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
Status: NEW → ASSIGNED
Attachment #264485 - Flags: superreview?(neil)
Attachment #264485 - Flags: review?(neil)

Updated

12 years ago
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+

Updated

12 years ago
Depends on: 380641
Reporter

Updated

12 years ago
Blocks: 363700
No longer depends on: 363700
Assignee

Updated

12 years ago
Blocks: 380786
Reporter

Updated

12 years ago
Blocks: 336874
No longer depends on: 336874
Reporter

Updated

12 years ago
Blocks: 381159
Assignee

Updated

12 years ago
No longer blocks: 381159
Reporter

Updated

12 years ago
Blocks: 381157
Reporter

Updated

12 years ago
Depends on: 381186
Assignee

Comment 15

12 years ago
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)
Reporter

Updated

12 years ago
Blocks: 381338
Reporter

Updated

12 years ago
Blocks: 381343
Assignee

Updated

12 years ago
Blocks: 278831
Attachment #265285 - Flags: review?(rhelmer) → review+
Reporter

Updated

12 years ago
Depends on: 381483
Assignee

Updated

12 years ago
Blocks: 381780

Updated

12 years ago
Depends on: 381915
Reporter

Updated

12 years ago
Depends on: 382168
Assignee

Updated

12 years ago
Blocks: 382187

Updated

12 years ago
Depends on: 382243

Updated

12 years ago
Depends on: 382245
Assignee

Comment 16

12 years ago
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!
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Reporter

Updated

12 years ago
Blocks: 382425
Reporter

Updated

12 years ago
Blocks: 382500

Updated

12 years ago
Blocks: 382449
Reporter

Updated

12 years ago
Blocks: 382585
Reporter

Updated

12 years ago
Blocks: 382586
Reporter

Updated

12 years ago
Blocks: 382795
Assignee

Updated

12 years ago
Blocks: 292075

Updated

12 years ago
Depends on: 383252

Updated

12 years ago
Depends on: 384712
Reporter

Updated

12 years ago
Blocks: 385056
Assignee

Updated

12 years ago
Blocks: 366673
No longer depends on: 366673
You need to log in before you can comment on or make changes to this bug.