Error: Components.classes['@mozilla.org/preferences-service;1'].getService(Components.interfaces.nsIPrefService).getBoolPref is not a function Source File: chrome://communicator/content/nsContextMenu.js Line: 283 How to reproduce: Build an extension. Import as overlay: contentAreaContextOverlay.xul This pulls in nsContextMenu.js. Attempt to use the contextmenu from extension. This is LXR's view of the file: <http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/nsContextMenu.js#281> At around line 283 we have something like: this.autoDownload = Components.classes["@mozilla.org/preferences-service;1"] .getService(Components.interfaces.nsIPrefService) .getBoolPref("browser.download.autoDownload"); According to XULPlanet, getBoolPref is a method of nsIPrefBranch, not nsIPrefService. According to BONSAI this was checked in as part of bug 7840. See: <https://bugzilla.mozilla.org/attachment.cgi?id=167914> It appears that the same error from the checkin at <http://lxr.mozilla.org/seamonkey/source/extensions/p3p/resources/content/p3pSummary.js#200> was fixed, but not this.

Not sure how this slipped through, reporter could you check this fixes your issue?

> reporter could you check this fixes your issue? I can confirm that fishing the nsContextMenu.js out of the jar file, modifying it and putting back the modified file fixes this error. Question: why isn't this bug triggered when called from navigator.xul with exactly the same context menu and nsContextMenu.js? By the way, should "this.autoDownload" also be in: <http://lxr.mozilla.org/seamonkey/source/mail/base/content/nsContextMenu.js#237>

(In reply to comment #2) >Question: why isn't this bug triggered when called from navigator.xul with >exactly the same context menu and nsContextMenu.js? Basically JavaScript interacts indirectly with C++ objects via an xpconnect wrapper which maintains a cache of the available methods. However each window also maintains a list of active wrappers. This means that if you retrieve a C++ object while its wrapper is still active the wrapper is reused. In this case the wrapper that the context menu retrieves in the navigator window happens to reuse the gPref variable that navigator.js created, whereas your extension's window has no cached wrapper to identify the availability of the getBoolPref method.

Comment on attachment 207256 [details] [diff] [review] Simple fix (d'oh) v0.1 (Checked in trunk/branch 1.8 & 1.8.0) /me thinks jag could easily have given r+sr on this

Comment on attachment 207256 [details] [diff] [review] Simple fix (d'oh) v0.1 (Checked in trunk/branch 1.8 & 1.8.0) Probably best this goes into 1.0 and 1.1, so requesting approval

Comment on attachment 207256 [details] [diff] [review] Simple fix (d'oh) v0.1 (Checked in trunk/branch 1.8 & 1.8.0) a=me for 1.0 and 1.1; 1.0 needs a second approval

Comment on attachment 207256 [details] [diff] [review] Simple fix (d'oh) v0.1 (Checked in trunk/branch 1.8 & 1.8.0) second a=me

Comment on attachment 207256 [details] [diff] [review] Simple fix (d'oh) v0.1 (Checked in trunk/branch 1.8 & 1.8.0) Checking in (trunk) nsContextMenu.js; new revision: 1.112; previous revision: 1.111 done Checking in (branch 1.8) nsContextMenu.js; new revision: 1.108.2.4; previous revision: 1.108.2.3 done Checking in (branch 1.8.0) nsContextMenu.js; new revision: 1.108.2.2.2.2; previous revision: 1.108.2.2.2.1 done