331431 - toolkit.jar is a dumping ground for everything.

Status: RESOLVED INCOMPLETE

(Toolkit Graveyard :: XULRunner, defect)

Description

[Doug Turner (:dougt)]

quickly looking through the toolkit.jar file, i find a bunch of stuff that is either only used in firefox, or only used in the old xpfe code, or doesn't seam like it is really part of a "toolkit" and is more application specific.  Here is an list of the stuff that I am wondering "why is it in toolkit", or should we conditionally put this in toolkit.jar based on what we are building.

passwordmgr\*
mozapps\*
help\*
global\alerts
global\charsetOverlay.js
global\charsetOverlay.xul
global\console.css
global\console.js
global\console.xul
global\consoleBindings.xml
global\contentAreaUtils.js
global\customizeCharset.js
global\customizeCharset.xul
global\customizeToolbar.css
global\customizeToolbar.js
global\customizeToolbar.xul
global\debug.js
global\dialogOverlay.js
global\dialogOverlay.xul
global\editMenuOverlay.js
global\editMenuOverlay.xul
global\filepicker.js
global\filepicker.xul
global\findBar.js
global\findUtils.js
global\finddialog.js
global\finddialog.xul
global\fontpackage.js
global\fontpackage.xul
global\fullScreen.js
global\globalOverlay.js
global\globalOverlay.xul
global\license.html
global\logo.gif
global\mozilla.xhtml
global\netError.xhtml
global\notfound.wav
global\nsClipboard.js
global\nsDragAndDrop.js
global\nsHelperAppDlg.xul
global\nsProgressDialog.xul
global\nsTreeController.js
global\nsTreeSorting.js
global\nsUserSettings.js
global\nsWidgetStateManager.js
global\plugins.html
global\print*
global\strres.js
global\viewPartialSource.js
global\viewPartialSource.xul
global\viewSource.css
global\viewSource.js
global\viewSource.xul
global\viewZoomOverlay.js
global\widgetStateManager.js


thoughts?

Comment 1

[Benjamin Smedberg]

Basically everything in that list is part of the shared toolkit and not part of the apps: in general we want to ship all this stuff in XULRunner (extension manager, update, help viewer, JS console, toolbar customization). I don't see any reason why they shouldn't live in toolkit.jar

Comment 2

[Doug Turner (:dougt)]

I removed the above stuff and saved .5mb.  I think we should strip out some of this stuff if we are building against the basic embedding profile.

Comment 3

[Benjamin Smedberg]

Absolutely... we don't need a lot of this for the embedding profiles, and it should be disabled using jar.mn ifdefs.

Comment 4

[Doug Turner (:dougt)]

Attachment: patch to remove stuff for Minimo

branch 1.8.1 only.  I think we should use the embedding profile defines for the trunk.

Tested this against minimo ce and it seams to work fine.

Comment 5

[Benjamin Smedberg]

Comment on attachment 216037 [details] [diff] [review]
patch to remove stuff for Minimo

In toolkit/locales/jar.mn you've added blank lines that will hork the non-minimo build... jar.mn isn't very forgiving.

Same in toolkit/themes/winstripe/global/jar.mn

I really think you want to be ifdefing all of toolkit/mozapps/extensions and toolkit/mozapps/update

Comment 6

[Benjamin Smedberg]

Comment on attachment 216037 [details] [diff] [review]
patch to remove stuff for Minimo

This is branch-only, right?

Comment 7

[Doug Turner (:dougt)]

yes.  1.8 only.  Lets keep this open until we fix the same thing on the trunk.  I would like to do this when you land 318041

Comment 8

[Steffen Wilberg]

Wouldn't it be cleaner to put #ifndefs in toolkit/components/Makefile.in instead of #ifndef'ing the whole content of the respective jar.mn's?

Comment 9

[Benjamin Smedberg]

We discussed this, and basically no (at least on the 1.8 branch)... toolkit/components/Makefile.in is already way too complicated.

Comment 10

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 11

[Benjamin Smedberg]

XULRunner has been removed from the Mozilla tree: see https://groups.google.com/forum/#!topic/mozilla.dev.platform/_rFMunG2Bgw for context.

I am closing all the bugs currently in the XULRunner bugzilla component, in preparation for moving this component to the graveyard. If this bug is still valid in a XULRunner-less world, it will need to be moved to a different bugzilla component to be reopened.