321981 - (nsContextMenu.js) Components.classes['@mozilla.org/preferences-service;1'].getService(Components.interfaces.nsIPrefService).getBoolPref is not a function

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Philip Chee]

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.

Comment 1

[Ian Neal]

Attachment: Simple fix (d'oh) v0.1 (Checked in trunk/branch 1.8 & 1.8.0)

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

Comment 2

[Philip Chee]

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

Comment 3

[[e-mail]]

(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 4

[[e-mail]]

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 5

[Ian Neal]

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 6

[Christian :Biesinger (don't email me, ping me on IRC)]

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 7

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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 8

[Ian Neal]

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