Closed Bug 336874 Opened 19 years ago Closed 12 years ago

Make suiterunner use the same toolkit.jar as XULRunner

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: kairo, Unassigned)

References

Details

(Whiteboard: [ToDo: comment 15])

Attachments

(1 file, 1 obsolete file)

first step, v 1.1: move lots of files to non-xul-app sections (checked in)
(deleted), patch
neil
: review+
benjamin
: superreview+
Details | Diff | Splinter Review 
If we want to base SeaMonkey on XULRunner in the future, we'll need base on the same toolkit.jar as XULRunner.
Currently xpfe/global is built "ifeq (,$(MOZ_PHOENIX)$(MOZ_XULRUNNER))" (actually in the else branch of the ifneq), so that means we need to stop building it at some point.
The first step to this should be moving everything that toolkit overrides into "#ifndef MOZ_XUL_APP" so that we clearly see what xpfe files still go into toolkit.jar as of now.
I think that effort should even help Thunderbird on its way towards XULRunner.

I went through http://lxr.mozilla.org/mozilla/search?string=toolkit.jar%3A basically today and should have figured out most of that stuff.

I'll attach a patch soon that does what I described "the first step" above :)
This moves all files I could find in toolkit's jar.mn lists to #ifndef MOZ_XUL_APP sections. It's basically all in xpfe/global/jar.mn but I also corrected one locale file in components/jar.mn and included toolkit's viewconfig in suiterunner builds (currently about:config is broken in suiterunner).
Attachment #221072 - Flags: superreview?(benjamin)
Attachment #221072 - Flags: review?(neil)
This patch is the same as the one before, but with a bit more changes to tookit/components/Makefile.in - it removes the double addition of feeds to DIRS that the bug 335443 checkin introduced (without being in the patch in that bug) and it makes suiterunner not exclude the feeds, printing and viewsource blocks.

The reason for this is that suiterunner builds are breaking after the checkin to bug 325080 because of a feeds inconsitency. With that patch, that bustage is fixed, and previously broken printing dialogs work (page setup and print... - print preview already did before). I have also tested that viewsource still works. BTW, I now have also verified that about:config does work again with this patch.
Attachment #221072 - Attachment is obsolete: true
Attachment #221133 - Flags: superreview?(benjamin)
Attachment #221133 - Flags: review?(neil)
Attachment #221072 - Flags: superreview?(benjamin)
Attachment #221072 - Flags: review?(neil)
Attachment #221133 - Flags: review?(neil) → review+
Comment on attachment 221133 [details] [diff] [review]
first step, v 1.1: move lots of files to non-xul-app sections (checked in)

You've tested tbird with this patch?
Attachment #221133 - Flags: superreview?(benjamin) → superreview+
I tested xpfe-based suite and toolkit-based suite with it and both work fine. I couldn't test Thunderbird as it couldn't get it to build even before doing that patch - but I'm only excluding files that are not overridden by toolkit.
It should build OK from what I see. Unfortunately, my Thunderbird build fails later linking thunderbird-bin due to some pango/xft problem, so I can't test the compiled build.
I'll check this in tomorrow afternoon European time and will try to get someone testing Thunderbird and/or download a nightly and test it myself as well.
Comment on attachment 221133 [details] [diff] [review]
first step, v 1.1: move lots of files to non-xul-app sections (checked in)

Checked in on trunk.

Attacking the files now still built for suiterunner (and Thunderbird) will need  more work, but now they are clearly indicated.
plugins.html for example is alse built into Firefox' toolkit.jar via a hack in /browser, I think we'll need to investigate more closely.
Attachment #221133 - Attachment description: first step, v 1.1: move lots of files to non-xul-app sections → first step, v 1.1: move lots of files to non-xul-app sections (checked in)
Blocks: 336860
OK, I tested a Thunderbird tinderbox build and could spot no problems that I could have caused :)

So, here's a list of files we're still using from xpfe and might need to get out of the way (XULRunner doesn't package them) - after that first patch, most of them are easy to spot:

content/global/hiddenWindow.xul
content/global/logo.gif
content/global/aboutAbout.html
content/global/about.xul
content/global/plugins.html
content/global/fullScreen.js
content/global/build.dtd
content/global/platformDialogOverlay.xul (mac/os2/unix/win)
content/global/platformDialog.xml (mac only)
content/global/platformXUL.css (mac/os2/unix/win)
locale/en-US/global-platform/win/nsWindowsHooks.properties

The about: stuff should probably made non-global, as the about window/page is usually app-specific, that has to dig into into core (nsAboutRedirector, etc.) though.

The plugins stuff is, as I said, hacked into Firefox as well, see http://lxr.mozilla.org/mozilla/source/browser/extensions/package-fixup/jar.mn
We should probably find a nice and generic solution for that as well.

I haven't investigated the others yet.
plugins stuff is 328678, which I hope to land this afternoon.
(In reply to comment #8)
> plugins stuff is 328678, which I hope to land this afternoon.

Nice (I think I know no files in our tree that were being moved around more than those) ;-)

BTW, we probably also can clean up some overrides in toolkit now that we're not packaging the xpfe files in the first place :)
Depends on: 328678
Depends on: 347872
Depends on: 363491
(In reply to comment #7)
>content/global/logo.gif
aboutRedirector could be pointed to chrome://branding/content/about.png

>content/global/aboutAbout.html
What, Firefox doesn't have this most useful page? ;-)

>content/global/about.xul
about dialog - deprecated,right?

>content/global/plugins.html
Already in toolkit, no?

>content/global/fullScreen.js
>content/global/build.dtd
Move to navigator, I guess

>content/global/platformDialogOverlay.xul (mac/os2/unix/win)
Only used by xpfe version of platformDialog.xul (which itself is unused)

>content/global/platformDialog.xml (mac only)
Only used by platformXUL.css (q.v.)

>content/global/platformXUL.css (mac/os2/unix/win)
Only used by xpfe version of xul.css

>locale/en-US/global-platform/win/nsWindowsHooks.properties
Move to navigator, I guess
Depends on: 381159
Moving bug 328887 so that this bug depends on it as that's really the right way round.
No longer blocks: suiterunner
Depends on: suiterunner
No longer depends on: 381159
Depends on: 381157
Almost a year since the last comment; since then, suiterunner has become the only supported Sm-trunk build.

I'm not well-versed enough in the SeaMonkey build process to be able to tell whether this bug is actually fixed or not.
(In reply to comment #12)
> I'm not well-versed enough in the SeaMonkey build process to be able to tell
> whether this bug is actually fixed or not.

Yes, but you should be able to see that there is still one dependent bug that is still open and hasn't been fixed yet (and actually there are two).
Depends on: 390025
(In reply to comment #13)
> (In reply to comment #12)
> > I'm not well-versed enough in the SeaMonkey build process to be able to tell
> > whether this bug is actually fixed or not.
> 
> Yes, but you should be able to see that there is still one dependent bug that
> is still open and hasn't been fixed yet (and actually there are two).
> 
Well, yes, sorry, I should have checked. However, I have seen bugs marked FIXED even though they were "Dependent" upon unfixed bugs...
QA Contact: ui-design
Comment on attachment 221133 [details] [diff] [review]
first step, v 1.1: move lots of files to non-xul-app sections (checked in)

(Bug 381157 landed today.)

Currently remaining parts (based on this patch (only)), afaict:


>RCS file: /cvsroot/mozilla/toolkit/components/Makefile.in,v

http://mxr.mozilla.org/mozilla1.9.1/source/toolkit/components/Makefile.in
{
88 ifndef MOZ_SUITE
89 ifndef MOZ_THUNDERBIRD
90 DIRS += search
91 endif
92 endif
}


>RCS file: /cvsroot/mozilla/xpfe/global/jar.mn,v

(nothing: probably done by bug 363491)


>RCS file: /cvsroot/mozilla/xpfe/components/jar.mn,v

http://mxr.mozilla.org/mozilla1.9.1/source/xpfe/components/autocomplete/jar.mn
{
1 toolkit.jar:
2     content/global/autocomplete.xml                             (resources/content/autocomplete.xml)
3     content/global/autocomplete.css                             (resources/content/autocomplete.css)
}
Whiteboard: [ToDo: comment 15]
(In reply to comment #15)
> (From update of attachment 221133 [details] [diff] [review])
> (Bug 381157 landed today.)
> 
> Currently remaining parts (based on this patch (only)), afaict:

...
> http://mxr.mozilla.org/mozilla1.9.1/source/xpfe/components/autocomplete/jar.mn

Bug 452232 is what is required before this can happen (plus I expect some tidy up that Neil wants to do) and you'd need to get rid of the ifdefs in http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/xul.css too.
Depends on: 452232
(In reply to comment #16)

> Bug 452232 is what is required before this can happen (plus I expect some tidy
> up that Neil wants to do) and you'd need to get rid of the ifdefs in

Good to know ;-)

> http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/xul.css too.

{
714 %elifdef MOZ_SUITE
715 %define AUTOCOMPLETE_OLD_STYLE
}
(In reply to comment #16)
> Bug 452232 is what is required before this can happen (plus I expect some tidy
> up that Neil wants to do) and you'd need to get rid of the ifdefs in
> http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/xul.css too.
Presuming that 452232 allows Thunderbird to switch to the toolkit autocomplete, we still need the xpfe autocomplete for our URLbar and editor link dialog to name two places, so we would need to move it into our repo under communicator in a similar way to what we do for notifications, toolbars and prefpanes.
(In reply to comment #15)

> http://mxr.mozilla.org/mozilla1.9.1/source/toolkit/components/Makefile.in
> 88 ifndef MOZ_SUITE
> 89 ifndef MOZ_THUNDERBIRD
> 90 DIRS += search

Anyone would know what we would have to do about this one?
Depends on: 547653
Bug 547653 doesn't block this one. This is about making the same toolkit.jar as xulrunner. Changing a couple of ifdefs doesn't help this one at all.

Although as toolkit/components/search doesn't actually define any chrome, then it doesn't actually affect this bug. It would only be the autocomplete changes that are left blocking this afaict.
No longer depends on: 547653
(In reply to comment #20)
> Bug 547653 doesn't block this one. This is about making the same toolkit.jar as
> xulrunner. Changing a couple of ifdefs doesn't help this one at all.

I concur: I just wanted to have a reminder for now then comment when it's resolved...
Depends on: 551503
Assignee: kairo → nobody
Depends on: 635831
AFAIK, this is not a goal any more (but as I did a patch in here, it shows up in a radar of "bugs where I did patches but the bug isn't resolved").
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #22)
> AFAIK, this is not a goal any more (but as I did a patch in here, it shows
> up in a radar of "bugs where I did patches but the bug isn't resolved").

What happened? I thought this was the "next big thing" in the Mozilla trends of where the technology is going. Got a link?
What happened is that XULRunner didn't become the platform, the web did.
Firefox, Thunderbird and other applications are not targeting to be XULRunner-based (i.e. shared XULRunner etc.) any more, and all focus at Mozilla has shifted on making web apps the great thing of the future, providing APIs to them so the web can be the future to build apps on, using HTML+CSS+JS instead of XUL+CSS+JS.
Given that, there's no reason for SeaMonkey to run after platform goals that everyone at Mozilla else has abandoned. And no, I don't have a link, there was no big announcement, this was just gradual change over time.
It's actually possible to build SeaMonkey based on XULRunner but LDAP autocomplete doesn't quite work properly yet.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: