14999 - Kill "toolkit" and "profile" appcores

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[Bill Law]

This bug is to track progress on the "Necko/progress support/appcores" item on
Brendan's "TODO list from today's 4pm meeting" email, sent 1999/09/24.

Two appcores remain (plus support code for the "base" implementation and the
"app cores manager").

The "toolkit" core will be removed entirely.  This will be accomplished by
changing (the few remaining) uses to use window.open or window.openDialog.

The "profile" core will be converted to use an xpidl-defined interface and a
standard implementation of that interface.  The corresponding JS code will be
modified to use conventional xpconnect techniques for creating instances of this
implementation and for invoking methods on those instances.

Comment 1

[Alec Flett]

I think that the profile core is not doing anything actually.
I already filed a bug against racham on this, but I think that sspitzer will
probably end up doing the work

Comment 2

[(not reading, please use [e-mail] instead)]

I'll take this bug, since I'm cleaning house in that code anyway.

Comment 3

[(not reading, please use [e-mail] instead)]

I should have said, "I'll take the killing profile appcore" part of the bug.

bill, can you work on killing toolkit?

I'm working on killing profile right now, and when I do, I'll report back here.

Comment 4

[Bill Law]

Yes, I'll finish off the toolkit core.  There's still some recalcitrant code in
both mailnews and editor that use it (as I recall) so I may come looking for
minor assistance (review of my changes).

Comment 5

[(not reading, please use [e-mail] instead)]

fixed.

the profile appcore is removed.

re-assigning to law, so he can remove the toolkit appcore.

Comment 6

[Bill Law]

I've completed the first step (in my working directory; this is not checked-in
yet) which was to remove all references to the toolkit core in the various .js
files.  There were 8 such files:

mozilla\editor\ui\composer\content\EditorCommands.js
mozilla\editor\ui\composer\content\sb-bookmarks.js
mozilla\intl\strres\tests\strres-test.js
mozilla\mailnews\base\resources\content\widgetglue.js
mozilla\xpfe\browser\src\nsBrowserInstance.cpp
mozilla\xpfe\global\resources\content\tasksOverlay.js
mozilla\xpinstall\res\xpistatus.js
mozilla\xpinstall\res\content\xpistatus.js

There were 3 ToolkitCore methods used in these files:

Close - these were replaced with "window.close()"
ShowWindow - these were replaced with "window.open"
ShowWindowWithArgs - these were replaced with "window.openDialog"

Remaining tasks:

1. The latter causes the argument to be passed via a different mechanism.  I now
must change the .xul/.js for the opened windows to deal with that.

2. Any C++ code that uses toolkit core services must also be changed.

3. One complication: there were a couple of instances of appcores being passed
by name from parent window to child dialog.  This relies on appcores and the app
core manager which are obsolete.  So this code must be redesigned.  I did that
in the case of the browser so it's a known quantity and shouldn't be a problem.

ETA for completion is early next week.

Comment 7

[Bill Law]

I've been working on the C++ code that uses the toolkit app core.  This occurs
in these files:

mozilla\editor\base\nsEditorShell.cpp
mozilla\mailnews\compose\src\nsMsgComposeService.cpp
mozilla\xpfe\appshell\src\nsCommandLineServiceMac.cpp
mozilla\xpfe\appshell\src\nsWebShellWindow.cpp
mozilla\xpfe\bootstrap\nsAppRunner.cpp

Each of these was calling ShowWindowWithArgs (surprise, surprise).  I've changed
them so they use nsIDOMWindow::OpenDialog.  This requires a "parent" window for
which I've utilized the app shell service's "hidden window."  This is a real
PITA so I've simplified things considerably by adding a convenience function to
nsIAppShellService: GetHiddenWindowAndJSContext.  The .idl and .cpp for that
will be going in first.  Then the updated .cpp files that use this new method.

Most of the modified JS is opening dialogs that already can deal with accepting
arguments via window.arguments[] so that step should be easy.  I'm going to look
at that next.  We should also go back and remove the obsolete support for the
"args" <broadcaster> that ShowWindowWithArgs used.

I'm going to try to get most of this checked in tomorrow.  My Mac build is dead
(builds, but won't run) so I've kind of hit a snag.  I've submitted all the .js
file changes for review and those have been approved.  I'll be sending out the
.cpp changes tomorrow morning.  If you get a request for review, please don't
ignore it (the changes are relatively straightforward).

The nsIAppShellService enhancement has been reviewed.

Comment 8

[Bill Law]

All C++ code using toolkit app core is fixed, with exception of nsWebShellWindow
and nsCommandLineServiceMac.  I've been pre-empted by higher priority bugs.  The
code is written I just need reviews and checkin.  Should be RSN.

Should I expand on this bug to handle the app core "name set" and app cores
manager, also?  Those can go away now and should.

Comment 9

[Bill Law]

The appcores are no longer used.  Remaining to do is the removal of the
mozilla/xpfe/AppCores directory from the build.  I'm leaving this bug in place
to track that but it will be deferred till post-m11.  The security issue should
be resolved (which perhaps makes this no longer [DOGFOOD]).

Comment 10

[don]

Move to M13 since it's not dogfood.

Comment 11

[leger]

Updating QA Contact.

Comment 12

[don]

Not a beta 1 requirement.

Comment 13

[(not reading, please use [e-mail] instead)]

sfraser did the hard work, when he removed AppCores from the mac build.
I followed his lead, and removed it for linux and windows.

now mozilla/xpfe/AppCores is removed from the tree.

marking this fixed.

Comment 14

[Paul MacQuiddy]

verified