Closed
Bug 18638
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] Need to be able to access XPConnect
Categories
(Core :: Preferences: Backend, defect, P3)
Core
Preferences: Backend
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: waterson, Assigned: mike+mozilla)
Details
(Whiteboard: [PDT+]Waterson to verify when he has time.)
I *need* to be able to access XPConnect in viewer. This is the only way that I can isolate some of my bugs. Please make this work!!!! thanks, chris
Reporter | ||
Comment 1•25 years ago
|
||
...and no, viewer doesn't read prefs, so setting the magic XPConnect pref doesn't work.
Comment 2•25 years ago
|
||
Is there a macro defined for viewer that's off for apprunner? Then I could turn off security.
Summary: [DOGFOOD] → [DOGFOOD]Need to be able to access XPConnect
Whiteboard: [PDT+]
Reporter | ||
Updated•25 years ago
|
Severity: blocker → normal
Reporter | ||
Comment 4•25 years ago
|
||
okay, i figured out how to "#if 0" out the thing that was tripping me up. I don't think you want a macro: the same caps.dll code will be used in both apprunner and viewer. Maybe some global variable? Or maybe we just need to make viewer read in prefs. In which case this really isn't your problem.
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] Should be fixed 11/26
Updated•25 years ago
|
Status: NEW → ASSIGNED
Summary: [DOGFOOD]Need to be able to access XPConnect → [DOGFOOD] Need to be able to access XPConnect
Romoving PDT+ for anoth review per norris' comments via mail: "This isn't even apprunner, but viewer. Is this really dogfood? Can't people use apprunner if they need to try out XPConnect components? I'm trying to figure out how to get my PDT+ bugs fixed in the next 12 days and not having to worry about this would help."
Updated•25 years ago
|
Whiteboard: Should be fixed 11/26
Mike, would you look into this one? Norris has some information: running tests requires altered security access which is done via prefs. Testing is often done in Viewer which does not use prefs and there isn't a good alternate mechanism. Norris suggests a couple of possible approaches: move the Apprunner prefs mechanism to viewer so it can handle prefs, or figure out a way to determine whether viewer or apprunner is in control. If viewer, turn off security. Please let me know if this seems approachable.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•25 years ago
|
||
Waterson - "i figured out how to '#if 0' out the thing that was tripping me up" ... which is that? Accepting bug as assigned.
Comment 10•25 years ago
|
||
Putting on the PDT+ radar.
Assignee | ||
Updated•25 years ago
|
Component: Security → libPref
Assignee | ||
Comment 11•25 years ago
|
||
Here's what I've found out so far. Documenting, changing component to libPref, and CC'ing in case somebody can suggest a good solution. Viewer *has* prefs, but fails silently when initializing the prefs object at nsPref.cpp:pref_InitInitialObjects(). The relevant code is NS_WITH_SERVICE(nsIFileLocator, locator, kFileLocatorCID, &rv); if (NS_FAILED(rv)) return JS_TRUE; (*why* return JS_TRUE on failure?) The NS_WITH_SERVICE call fails to find an nsIFileLocator with an NS_ERROR_FACTORY_NOT_REGISTERED result. nsIFileLocator is implemented in xpfe/appshell; is the viewer seeing it? All hints welcome.
Comment 12•25 years ago
|
||
nsIFileLocator is not being registered with viewer. I tried adding the nsComponentManager::RegisterComponentLib(kFileLocatorCID, ...) call to mozilla/viewer/nsSetupRegistry.cpp file. After this is done, all the prefs get read. This is a hack since we are making viewer depend on appshell.dll. I have attached the diffs below. Neeti cvs server: Diffing . Index: nsSetupRegistry.cpp =================================================================== RCS file: /cvsroot/mozilla/webshell/tests/viewer/nsSetupRegistry.cpp,v retrieving revision 1.152 diff -c -r1.152 nsSetupRegistry.cpp *** nsSetupRegistry.cpp 1999/11/24 03:41:45 1.152 --- nsSetupRegistry.cpp 1999/11/24 17:21:31 *************** *** 50,55 **** --- 50,58 ---- #include "nsISound.h" #include "nsIFileSpecWithUI.h" + #include "nsFileLocations.h" + #include "nsIFileLocator.h" + #if defined(XP_UNIX) && !defined(MOZ_MONOLITHIC_TOOLKIT) #include "nsIUnixToolkitService.h" #endif *************** *** 67,72 **** --- 70,76 ---- #define PLUGIN_DLL "gkplugin.dll" #define CAPS_DLL "caps.dll" #define LIVECONNECT_DLL "jsj3250.dll" + #define APPSHELL_DLL "appshell.dll" #define OJI_DLL "oji.dll" #elif defined(XP_MAC) #define WIDGET_DLL "WIDGET_DLL" *************** *** 165,170 **** --- 169,177 ---- static NS_DEFINE_IID(kCPluginHostCID, NS_PLUGIN_HOST_CID); static NS_DEFINE_CID(kCPluginManagerCID, NS_PLUGINMANAGER_CID); + static NS_DEFINE_CID(kFileLocatorCID, NS_FILELOCATOR_CID); + + // OJI #ifdef OJI static NS_DEFINE_CID(kCLiveconnectCID, NS_CLIVECONNECT_CID); *************** *** 354,359 **** --- 361,368 ---- // PLUGIN nsComponentManager::RegisterComponentLib(kCPluginHostCID, NULL, NULL, PLUGIN _DLL, PR_FALSE, PR_FALSE); nsComponentManager::RegisterComponentLib(kCPluginManagerCID, NULL, NULL, PLU GIN_DLL, PR_FALSE, PR_FALSE); + + nsComponentManager::RegisterComponentLib(kFileLocatorCID, NULL, NS_FILE LOCATOR_PROGID, APPSHELL_DLL, PR_FALSE, PR_FALSE); #ifdef OJI nsComponentManager::RegisterComponentLib(kCLiveconnectCID, "LiveConnect", "c omponent://netscape/javascript/liveconnect", LIVECONNECT_DLL, PR_FALSE, PR_FALSE ); cvs server: Diffing mac cvs server: Diffing public cvs server: Diffing resources cvs server: Diffing samples cvs server: Diffing throbber cvs server: Diffing unix cvs server: Diffing unix/gtk cvs server: Diffing unix/motif cvs server: Diffing unix/qt cvs server: Diffing unix/xlib
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 13•25 years ago
|
||
Fixed with recent checkin. Thanks, Neeti. (Whoops, forgot to put r=neeti on the checkin message :( )
Comment 14•25 years ago
|
||
Looks to be an internal development issue. Waterson has this issue been solved?
Assignee | ||
Comment 15•25 years ago
|
||
This is just about fixed; I actually had to back out my fix because of bustage. Waterson, could you confirm after I land?
Reporter | ||
Updated•25 years ago
|
QA Contact: dshea → waterson
Reporter | ||
Comment 16•25 years ago
|
||
yes, just poke the bug and i'll verify
Assignee | ||
Comment 17•25 years ago
|
||
Fix re-landed. Waterson?
Comment 19•25 years ago
|
||
Moving all libPref component bugs to new Preferences: Backend component. libPref component will be deleted.
Component: libPref → Preferences: Backend
Comment hidden (spam) |
You need to log in
before you can comment on or make changes to this bug.
Description
•