632422 - XPCOM objects retrieved from different scopes aren't strictly equal

Status: NEW

(Core :: XPConnect, defect)

Description

[Rain [:rain1] (inactive)]

STR:

Components.utils.import("resource://gre/modules/Services.jsm");
var ct1 = Services.tm.currentThread;
var ct2 = Components.classes["@mozilla.org/thread-manager;1"].getService(Components.interfaces.nsIThreadManager).currentThread;
ct1 === ct2

returns false. ct1 == ct2 returns true.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is expected, no?  They're distinct objects; if you try to add expandos to one they won't show up on the other, for example.

Comment 2

[Boris Zbarsky [:bzbarsky]]

And in particular, Services and the code above live in different scopes, so can't get a hit on the wrappednative cache, I would think.

Comment 3

[Boris Zbarsky [:bzbarsky]]

But maybe the cache should be per-compartment, not per-scope?

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

/me likes WONTFIX for this.

Comment 5

[Benjamin Smedberg]

I don't think so: we don't want one JSM to be able to pollute these objects for another JSM.

Unless of course we take my suggestion and don't allow expandos on XPCOM objects from chrome at all, in which case per-compartment would be fine.

Comment 6

[Rain [:rain1] (inactive)]

From the perspective of an XPCOM user, I think it makes sense that Services.tm !== the service if you get it directly, but it doesn't intuitively make sense that something you get from the service differs based on which scope the service is in. In particular, it means that current getService code cannot be replaced wholesale with the Services equivalent, since stuff like Array.indexOf breaks.

Comment 7

[Benjamin Smedberg]

I don't understand the last comment at all.

Comment 8

[Rain [:rain1] (inactive)]

If I have code somewhere that looks like:

var thread = Components.classes["@mozilla.org/thread-manager;1"].getService(Components.interfaces.nsIThreadManager).currentThread;
if (arr.indexOf(thread) != -1) { ... }

I can't replace it with

var thread = Services.tm.currentThread;
if (arr.indexOf(thread) != -1) { ... }

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #5)
> I don't think so: we don't want one JSM to be able to pollute these objects for
> another JSM.

By default, XPConnect doesn't allow you to add expandos to an object unless it has a scriptable helper that explicitly sets the right flags (USE_JSSTUB_FOR_{SET,ADD}PROPERTY or WANT_{ADD,SET}PROPERTY). The only pollution really would be through Object.prototype. The reason being (as I understand it) is that we can't reflect expandos into C++, so unless your object explicitly says "I can deal with my reflections into different languages being different" we don't allow the reflections to differ.