582012 - getstringidentifier() returns different NPIdentifiers (OOPP)

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Arnaud]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1 ( .NET CLR 3.5.30729)

I have implemented a plugin that call the function getstringidentifier() provided by the browser to convert a method name to a NPIdentifier.
When a method is invoked on the plugin, the plugin compares the input NPIdentifier to cached NPIdentifiers for all methods of my object to
find the requested method.
It has worked fine in FF 2, 3, 3.5, 3.6.

In Firefox 4.0b1, if the the OOPP (out-of-process plugin) mode is disabled, it also works. But if OOPP is enabled (default), it doesn't work well because
sometimes the input NPIdentifier doesn't match any IDs, especially
just after browser startup.

After some debugging, I have discovered that getstringidentifier()
returns different NPIdentifiers for the _same_ method name at
different times, in a single browser session.

Reproducible: Sometimes

Steps to Reproduce:
Start Firefox.
Open a page with 1 plugin instance defined in the HTML source.
Press a button that calls a scriptable method.
(I cannot provide my plugin.)
Actual Results:  
JS cannot call the plugin method.
An error "yyyy.xxxx is not a function" is displayed in the JS console.

Expected Results:  
JS can call the plugin method.
NPIdentifiers for the same method name should not change during a single session.

Comment 1

[Benjamin Smedberg]

In order to help us reproduce this issue, can you help provide a more exact sequence of events, and the exact APIs your plugin is calling?

-> NP_Initialize
  -< NPN_GetStringIdentifiers
  Do you call NPN_GetStringIdentifiers here, or sometime later, perhaps during NPP_New or the first NPRuntime call?
  Are you calling NPN_GetStringIdentifier, or NPN_GetStringIdentifiers?

Comment 2

[Martin Husemann]

I am using a very similar technique in my plugins, maybe with two differences: I only ask for a single identifier at a time (NPN_GetStringIdentifier), and I only do that lazyly on first call/access to a scriptable function or property.

I have, so far, been unable to reproduce the problem, but maybe it was just luck.

Comment 3

[Arnaud]

(In reply to comment #1)
I have reproduced the same kind of problem without NPIdentifier caching, in the HasMethod() provided by my scriptable object:

bool KPluginProxy::HasMethod(NPIdentifier methodID) {

	string methodStr = NPGetMethodName(methodID); // // wrapper around GetNPNFuncs()->utf8fromidentifier;
	NPIdentifier methodID2 = (*GetNPNFuncs()->getstringidentifier)(methodStr.c_str());
	if (methodID != methodID2) { // !!!

		MessageBox(...);
        }
 ...

Just after browser startup, if I call the method from JS, the MessageBox is displayed. However 'methodStr' is correct.
After a page refresh, it works as expected.

Comment 4

[Benjamin Smedberg]

Indeed, when we get identifiers from the browser we're not adding them to the hashtable, which causes us to create a new one instead of re-using the one we want. Many plugins call NPN_GetStringIdentifiers first, during NPP_New or when you create an object type, so they don't have this problem. But I'm not sure that Silverlight or Flash won't be subtly broken by this bug, so I think we should take this on branches as well.

Comment 5

[Benjamin Smedberg]

Attachment: Add them to the maps, rev. 1

Comment 6

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

Comment on attachment 460542 [details] [diff] [review]
Add them to the maps, rev. 1

Wow. Oops.

Comment 7

[Benjamin Smedberg]

http://hg.mozilla.org/mozilla-central/rev/a1ad34b3cdc2

Comment 8

[LegNeato]

Comment on attachment 460542 [details] [diff] [review]
Add them to the maps, rev. 1

a=LegNeato for 1.9.2.9.

Comment 9

[Mark Banner (:standard8)]

I believe this bug has caused a permanent orange on Mac on the 1.9.2 branch, see bug 584156 for details.

Comment 10

[Benjamin Smedberg]

There is absolutely no way this caused a problem on mac-1.9.2, since that code isn't even *built* on mac-1.9.2 ;-)

Comment 11

[Benjamin Smedberg]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/820b07cc1c48