334478 - Get suiterunner to actually run (start up a somewhat usable browser window)

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Robert Kaiser]

Currently "suiterunner" (SeaMonkey trunk with MOZ_XUL_APP=1) is building correctly on two of three tier-1 platforms, but it's not able to start up correctly yet.
This bug is for patches that enable us to start up a somewhat usable browser window.

Comment 1

[Robert Kaiser]

Attachment: set prefs to find navigator XUL and set theme correctly

This patch makes suiterunner find the Navigator window and set the default theme.

Comment 2

[[e-mail]]

Comment on attachment 218809 [details] [diff] [review]
set prefs to find navigator XUL and set theme correctly

browser.chromeURL is very much needed. Also you should note that  toolkit.chromeURI is a stop-gap until our default command line handler works.

Comment 3

[Robert Kaiser]

Attachment: default prefs changes, v2 (checked in)

OK, added a comment about the default command line handler and removed the else branch so that browser.defaultURL is also set for suiterunner

Comment 4

[[e-mail]]

Comment on attachment 218813 [details] [diff] [review]
default prefs changes, v2 (checked in)

>+// XXX When SeaMonkey becomes a full xul app the non-moz_xul_app part of this
>+// can be removed.
Oops ;-)

Comment 5

[Robert Kaiser]

Comment on attachment 218813 [details] [diff] [review]
default prefs changes, v2 (checked in)

sorry again for checkin this in early.
Fixed the comment to
// XXX When SeaMonkey becomes a full xul app this can be set without an ifdef

Comment 6

[Robert Kaiser]

Attachment: communicator chrome registration changes

Somehow the extra "platform" on the communicator-platform registration line is causing XML errors, so remove it. Additionally, add xpcnativewrappers for all those lines.

Comment 7

[Robert Kaiser]

Comment on attachment 219069 [details] [diff] [review]
communicator chrome registration changes

Removing "pltform" is actually wrong. We have to convert locale over to the new registration model instead.

Comment 8

[Robert Kaiser]

Attachment: move communicator platform and region to new location and registration

This one should fix the inconsistency seen in communicator-platform in a better way. The region, xpcnativewrappers and communicator/contents.rdf changes are not strictly needed, but those should happen anyways at some point and are easily done along with this patch, so I've included them.
The good thing is that only the content part of the registration in the xpfe jar.mn is used by thunderbird, the locale stuff is completely forked into mail/ so we can just move it to suite without further thinking.
Those files are small enough to go without cvs moves, IMO (which also enables us to make it happen fast).

Comment 9

[[e-mail]]

a) I'm not convinced on the moves b) I think we need to register overlays

Comment 10

[Robert Kaiser]

Attachment: make communicator chrome register correctly (checked in)

Here's a "minimal" patch for correcting the communicator chrome registration stuff. This includes the missing overlays and also branding though (ifdefed to be used by suite only).
Note that we hardcode en-US locale here, as we don't use any @AD_CD@ replacing in that file yet, and it makes no sense to introducethe ability to do so right now - we'll win that by moving that over to suite/locales/ later in a different bug.

Comment 11

[Robert Kaiser]

Comment on attachment 219205 [details] [diff] [review]
make communicator chrome register correctly (checked in)

OH, BTW, in the new overlay lines this also removes the double-overlaying of imageContextOverlay.xul done in contents.rdf (this has r+sr=jag over IRC)

Comment 12

[[e-mail]]

Comment on attachment 219205 [details] [diff] [review]
make communicator chrome register correctly (checked in)

Nit: xpcnativewrappers=yes

Comment 13

[Robert Kaiser]

(In reply to comment #12)
> (From update of attachment 219205 [details] [diff] [review] [edit])
> Nit: xpcnativewrappers=yes

Argh, sure, I had that in the other patch, got lost when doing the new one, changed locally for checkin (which I'll do first thing tomorrow when I get up)...

Comment 14

[Robert Kaiser]

Comment on attachment 219205 [details] [diff] [review]
make communicator chrome register correctly (checked in)

This one's checked in as well (along with the xpcnativewrappers=yes flags)

Comment 15

[[e-mail]]

Attachment: Patch to kill toolkit chrome for test purposes

With this patch I get useful stuff: primary toolbars, help, JS console etc ;-)

Comment 16

[Robert Kaiser]

(In reply to comment #15)
> Created an attachment (id=219285) [edit]
> Patch to kill toolkit chrome for test purposes
> 
> With this patch I get useful stuff: primary toolbars, help, JS console etc ;-)

This sure is only for test purposes, as bsemdberg surely won't let us introduce another set of bad and masty ifdefs into toolkit. We really should work on moving most stuff we need there out of the chrome://global/ namespace (and into chrome://communicator/ probably) or use the toolkit equivalents where provided.
The help stuff looks to me like something that should change on the toolkit side though.

Comment 17

[[e-mail]]

Attachment: ... and restore some xpfe chrome too

Only to be used for testing in conjunction with the previous patch.

Comment 18

[[e-mail]]

Attachment: Functional default command line handler

There are some scary changes to nsBrowserInstance.cpp which is because there's no way to expose the default page (which for an upgrade is the override page) in the way we used to be able to do.

Comment 19

[Robert Kaiser]

Comment on attachment 219298 [details] [diff] [review]
Functional default command line handler

>+# XXX browser-prefs.js should be moved to within the /suite directory at

Yes, browser-pref.js should move here, but the comment is incomplete ;-)

Comment 20

[Robert Kaiser]

Attachment: make help locale work (checked in)

toolkit packages its own help locale files into the locale .jar, and that interferes with extensions/help filling up help locale.

This patch fixes help by overriding the two locale files that we want to package (in tier_99) but toolkit already has packed them (in tier_50).

Comment 21

[[e-mail]]

Comment on attachment 219302 [details] [diff] [review]
make help locale work (checked in)

Somewhat annoying, but at least it doesn't seem to conflict with symlinked chrome.

Comment 22

[Robert Kaiser]

Comment on attachment 219302 [details] [diff] [review]
make help locale work (checked in)

Checked in this fix as well :)

Comment 23

[Robert Kaiser]

Attachment: use toolkit console, remove old xpfe files (checked in)

This patch makes us use the toolkit console as JS console, and removes some other, now unused xpfe files from suiterunner chrome along withg the xpfe console files.
We may later want to overlay the console to give us a menubar, but for now, we have a working JS console again (and one more piece of toolkit we're using).

Comment 24

[Robert Kaiser]

(In reply to comment #23)
> We may later want to overlay the console to give us a menubar, but for now, we
> have a working JS console again (and one more piece of toolkit we're using).

I've filed bug 334997 for that, and I'm working on a patch for it.

Comment 25

[[e-mail]]

Comment on attachment 219332 [details] [diff] [review]
use toolkit console, remove old xpfe files (checked in)

Nit: you can exclude finddialog and filepicker too.

Comment 26

[Robert Kaiser]

Comment on attachment 219332 [details] [diff] [review]
use toolkit console, remove old xpfe files (checked in)

Checked in this, along with the removal of finddialog and filepicker files from suiterunner.

Comment 27

[Robert Kaiser]

Comment on attachment 219298 [details] [diff] [review]
Functional default command line handler

This has been obsoleted by bug 335550

Comment 28

[Robert Kaiser]

Attachment: build themes before suite for correct mac packaging (checked in)

Mac suiterunner misses most of our theme files currently. We are actually running into a very similar problem to bug 338571 there: We are "packaging" the files into the app bundle on in suite/app and only after that we are adding the remaining files into the <theme>.jar files - and they never get shipped.
Because of that, we need to build themes before suite/ and then it works as it should, this patch does just that.

Comment 29

[Robert Kaiser]

Comment on attachment 222715 [details] [diff] [review]
build themes before suite for correct mac packaging (checked in)

Checked in as well.

Comment 30

[Robert Kaiser]

OK, marking this one fixed. It actually has been "somewhat" usable for some time now, all further work that is to be done is marked as dependencies of bug 328887, including the currently biggest dogfood stopper, bug 350221.