Closed Bug 14999 Opened 21 years ago Closed 20 years ago
Kill "toolkit" and "profile" appcores
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.
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
21 years ago
Assignee: law → sspitzer
I'll take this bug, since I'm cleaning house in that code anyway.
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.
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).
21 years ago
Assignee: sspitzer → law
fixed. the profile appcore is removed. re-assigning to law, so he can remove the toolkit appcore.
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.
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.
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.
Summary: Kill "toolkit" and "profile" appcores → [DOGFOOD] Kill "toolkit" and "profile" appcores
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]).
Move to M13 since it's not dogfood.
Updating QA Contact.
Summary: [DOGFOOD] Kill "toolkit" and "profile" appcores → Kill "toolkit" and "profile" appcores
Whiteboard: [PDT-][2 days]
Target Milestone: M13 → M15
Not a beta 1 requirement.
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.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.