[DOGFOOD] Need to be able to access XPConnect

VERIFIED FIXED in M12

Status

()

Core
Preferences: Backend
P3
normal
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: Chris Waterson, Assigned: Mike McCabe)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+]Waterson to verify when he has time.)

(Reporter)

Description

19 years ago
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

19 years ago
...and no, viewer doesn't read prefs, so setting the magic XPConnect pref
doesn't work.

Comment 2

19 years ago
Is there a macro defined for viewer that's off for apprunner? Then I could turn
off security.

Updated

19 years ago
Summary: [DOGFOOD] → [DOGFOOD]Need to be able to access XPConnect
Whiteboard: [PDT+]

Comment 3

19 years ago
Putting on PDT+ radar.
(Reporter)

Updated

19 years ago
Severity: blocker → normal
(Reporter)

Comment 4

19 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

19 years ago
Target Milestone: M12

Comment 5

19 years ago
Dogfood, putting on M12 radar.

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+] Should be fixed 11/26

Updated

19 years ago
Status: NEW → ASSIGNED
Summary: [DOGFOOD]Need to be able to access XPConnect → [DOGFOOD] Need to be able to access XPConnect

Updated

19 years ago
Whiteboard: [PDT+] Should be fixed 11/26 → Should be fixed 11/26

Comment 6

19 years ago
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

19 years ago
Whiteboard: Should be fixed 11/26

Updated

19 years ago
Assignee: norris → clayton
Status: ASSIGNED → NEW

Comment 7

19 years ago
Clayton -- can you get Norris some help on this one?

Updated

19 years ago
Assignee: clayton → mccabe

Comment 8

19 years ago
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

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 9

19 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.

Updated

19 years ago
Whiteboard: [PDT+]

Comment 10

19 years ago
Putting on the PDT+ radar.
(Assignee)

Updated

19 years ago
Component: Security → libPref
(Assignee)

Comment 11

19 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

19 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

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 13

19 years ago
Fixed with recent checkin.  Thanks, Neeti.

(Whoops, forgot to put r=neeti on the checkin message :( )

Updated

19 years ago
Blocks: 20203

Updated

19 years ago
QA Contact: junruh → dshea

Comment 14

19 years ago
Looks to be an internal development issue.
Waterson has this issue been solved?
(Assignee)

Comment 15

19 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

19 years ago
QA Contact: dshea → waterson
(Reporter)

Comment 16

19 years ago
yes, just poke the bug and i'll verify
(Assignee)

Comment 17

19 years ago
Fix re-landed.  Waterson?

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+]Waterson to verify when he has time.
(Reporter)

Comment 18

19 years ago
marking verified
Status: RESOLVED → VERIFIED

Comment 19

19 years ago
Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.
Component: libPref → Preferences: Backend

Updated

18 years ago
No longer blocks: 20203
You need to log in before you can comment on or make changes to this bug.