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)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: kairo, Unassigned)
References
Details
(Whiteboard: [ToDo: comment 15])
Attachments
(1 file, 1 obsolete file)
8.77 KB,
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 :)
Reporter | ||
Comment 1•19 years ago
|
||
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)
Reporter | ||
Comment 2•19 years ago
|
||
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)
Updated•19 years ago
|
Attachment #221133 -
Flags: review?(neil) → review+
Comment 3•19 years ago
|
||
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+
Reporter | ||
Comment 4•19 years ago
|
||
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.
Reporter | ||
Comment 5•19 years ago
|
||
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.
Reporter | ||
Comment 6•19 years ago
|
||
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)
Reporter | ||
Comment 7•19 years ago
|
||
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.
Comment 8•19 years ago
|
||
plugins stuff is 328678, which I hope to land this afternoon.
Reporter | ||
Comment 9•19 years ago
|
||
(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
Comment 10•18 years ago
|
||
(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
Comment 11•18 years ago
|
||
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
Comment 12•17 years ago
|
||
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.
Comment 13•17 years ago
|
||
(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
Comment 14•17 years ago
|
||
(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...
Updated•16 years ago
|
QA Contact: ui-design
Comment 15•16 years ago
|
||
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)
}
Updated•16 years ago
|
Whiteboard: [ToDo: comment 15]
Comment 16•16 years ago
|
||
(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
Comment 17•16 years ago
|
||
(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
}
Comment 18•16 years ago
|
||
(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.
Comment 19•16 years ago
|
||
(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?
Comment 20•15 years ago
|
||
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
Comment 21•15 years ago
|
||
(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...
Reporter | ||
Updated•14 years ago
|
Assignee: kairo → nobody
Reporter | ||
Comment 22•12 years ago
|
||
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
Comment 23•12 years ago
|
||
(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?
Reporter | ||
Comment 24•12 years ago
|
||
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.
Comment 25•12 years ago
|
||
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.
Description
•