NPAPI: === returns false for identical NPObjects returned from a plugin.

• Component: Plug-ins
• Status: RESOLVED INVALID

[Jeremy Moskovich]

The === JS operator appears to have a bug when comparing identical NPObjects returned from a plugin.

a = plugin.getObject();
b = plugin.getObject(); // Returns the same underlying object as the one above.

// a === b is false, a == b is true.

alert(a); // NPObject 0x865c3d4, NPClass 0x4d7e780
alert(b); // NPObject 0x865c3d4, NPClass 0x4d7e780
alert(typeof(a)); // object

[Mark Rowe (bdash)]

<rdar://problem/6130751>

[Jeremy Moskovich]

Correction == returns false as well.

[Thatcher Ulrich]

See https://bugs.webkit.org/show_bug.cgi?id=20305 for specific repro steps.

[Thatcher Ulrich]

Link to Chromium bug w/ specific repro steps: http://code.google.com/p/chromium/issues/detail?id=3786

Another Chrome bug on the same === failing issue has a recent fix for it. 

See http://code.google.com/p/chromium/issues/detail?id=5751

The problem appears to exist in the other direction too, i.e. when passing objects from JS to the plugin.

  var a = {};
  plugin.f(a, a); 

The plugin sees an argument list containing two different NPObject pointers.  On Firefox and Chrome, the same NPObject pointer appears twice in the list, allowing the plugin to test whether the arguments are the same.

[Alexey Proskuryakov]

This bug is in a pretty much useless state. Is it about Chrome or Safari, WebKit1 or WebKit2?

I've created a new bug for the JS -> plugin direction (which was under Safari)

https://bugs.webkit.org/show_bug.cgi?id=77404

[Anders Carlsson]

I think this works with WebKit2. If it doesn't work, we're not likely to fix it - our plug-in code is in maintenance mode only.