Closed
Bug 14999
Opened 25 years ago
Closed 25 years ago
Kill "toolkit" and "profile" appcores
Categories
(SeaMonkey :: UI Design, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
M15
People
(Reporter: law, Assigned: law)
References
Details
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•25 years ago
|
||
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
Updated•25 years ago
|
Assignee: law → sspitzer
Comment 2•25 years ago
|
||
I'll take this bug, since I'm cleaning house in that code anyway.
Comment 3•25 years ago
|
||
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).
Updated•25 years ago
|
Assignee: sspitzer → law
Comment 5•25 years ago
|
||
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]).
Comment 10•25 years ago
|
||
Move to M13 since it's not dogfood.
Comment 11•25 years ago
|
||
Updating QA Contact.
Summary: [DOGFOOD] Kill "toolkit" and "profile" appcores → Kill "toolkit" and "profile" appcores
Whiteboard: [PDT-][2 days]
Target Milestone: M13 → M15
Comment 12•25 years ago
|
||
Not a beta 1 requirement.
Comment 13•25 years ago
|
||
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: 25 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•