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
...and no, viewer doesn't read prefs, so setting the magic XPConnect pref doesn't work.
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
Putting on PDT+ radar.
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.
Dogfood, putting on M12 radar.
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."
Clayton -- can you get Norris some help on this one?
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.
Waterson - "i figured out how to '#if 0' out the thing that was tripping me up" ... which is that? Accepting bug as assigned.
Putting on the PDT+ radar.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Fixed with recent checkin. Thanks, Neeti. (Whoops, forgot to put r=neeti on the checkin message :( )
Looks to be an internal development issue. Waterson has this issue been solved?
This is just about fixed; I actually had to back out my fix because of bustage. Waterson, could you confirm after I land?
yes, just poke the bug and i'll verify
Fix re-landed. Waterson?
Status: RESOLVED → VERIFIED
Moving all libPref component bugs to new Preferences: Backend component. libPref component will be deleted.
Component: libPref → Preferences: Backend
You need to log in before you can comment on or make changes to this bug.