280932 - Scriptable plug-in API does not work on the Mac

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[Vlad Alexander]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: FF 1.0+, Mozilla 1.7.5+

The scriptable plug-in API does not work on the Mac. When a property on the
plug-in is called, browser tries to get scriptable object by calling
NPP_GetValue with NPPVpluginScriptableNPObject type, that is correct. But after
that, things are getting weird. When HasProperty method gets called, the
variable passed in the method like "name", is always empty. And the sequence of
calling this methods HasProperty, GetProperty, SetProperty is messed up. When a
property is called, it appears that the SetProperty is called first and then
GetProperty is called. And "NPIdentifier name" are always empty. There are other
 issues that are tricky to figure out and document.

Attached is a sample plug-in, C++ source code for XCode 1.5 and a test page.


Reproducible: Always

Steps to Reproduce:
1. Install plug-in
2. Open plugin.htm test page.
3. Click the 3 buttons under the plug-in

Actual Results:  
Not able to get data from the plug-in nor set (pass) data to the plug-in.

Expected Results:  
Click on "Get Value" should bring up a message box with the value "Hello
World!!!". Click on the "Set Value" should change internal value of the plug-in.
Click the "Get Value" or "Call toString()" buttons should bring up a message box
with the value "This is a new value".

Comment 1

[Vlad Alexander]

Attachment: Sample scriptable plug-in for the Mac

Comment 2

[Vlad Alexander]

Attachment: C++ source code for XCode 1.5

Comment 3

[Vlad Alexander]

Attachment: Test case HTML page to launch the plug-in

Comment 4

[Johnny Stenback (:jst)]

This looks like a plugin code problem to me. I see code that does things like this:

void CXEditor::GetStringFromIdt( NPIdentifier name, char *str )
{
        str[0] = '\0';
        if( name != NULL )
        {
                NPString *npstr = (NPString*)name;
                int len = npstr->UTF8Length;
                if( len == 1 ) //this is just for bug of safari,
                        len = strlen( npstr->UTF8Characters );
                strncpy( str, npstr->UTF8Characters, len );
                str[len] = '\0';
        }

That's assuming that an NPIdentifier is an NPString, which is never the case (at
least not in Mozilla, it's a jsval that may or may not be a string value).  Use
NPN_UTF8FromIdentifier(), and make sure you're dealing with a string identifier
here (or you'll get null back from that call). Check with
NPN_IdentifierIsString() to be sure.

And I'd be really surprised if there's really a bug in Safari here. Fix this
code to use the API like it was meant to be used first, and if you're still
seeing a problem in Safari, *then* claim it's a Safari bug.

And I also see a lot of code that checks the type of an NPVariant w/o using tyhe
macros that are provided in the API. You'll save yourself headaches down the
road if you use the macros as much as possible...

And for your info, your code would be smaller and faster if you'd store
NPIdentifiers for the identifiers you do use (value, toString, etc) in static
variables and compare the identifiers that you get to your static ones in stead
of converting the identifiers to strings only to do a string compare on them.
That way you don't need to worry about checking if an identifier is a string or
not, you just compare against the known ones you're interested in and your code
will do the right thing.

Fix all that, and then let us know how it's looking. Reopen this bug if there's
still some apparent problems with the API implementation on the Mac.