Bug 98739 – [EFL][WTR] plugins/npruntime/embed-property-equality.html fail

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit EFL

[KwangYong Choi]

Comparison of two javascript objects in C++ is failure.

Mac port has same problem. (bug 63205)

[Jussi Kukkonen (jku)]

Hmm, WebKit2 does not even have that test plugin, does it?

[KwangYong Choi]

(In reply to comment #1)
> Hmm, WebKit2 does not even have that test plugin, does it?

Plugin feature is enabled on EFL port after r129972. And, of course, test plugin is available.

Most of the plugin tests are passed. But some tests are not. Please see bug 98750.

[Jussi Kukkonen (jku)]

(In reply to comment #2)
> (In reply to comment #1)
> > Hmm, WebKit2 does not even have that test plugin, does it?
> 
> Plugin feature is enabled on EFL port after r129972. And, of course, test plugin is available.

Yes, this is true. What I was trying to say is that AFAIK WebKit2 does not have the _actual plugin_ you need for this test.

[KwangYong Choi]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Hmm, WebKit2 does not even have that test plugin, does it?
> > 
> > Plugin feature is enabled on EFL port after r129972. And, of course, test plugin is available.
> 
> Yes, this is true. What I was trying to say is that AFAIK WebKit2 does not have the _actual plugin_ you need for this test.

TestNetscapePlugin is used for WK2 plugin test. Is it necessary WK2 has own test plugin?

[Jussi Kukkonen (jku)]

(In reply to comment #4)
> TestNetscapePlugin is used for WK2 plugin test. Is it necessary WK2 has own test plugin?

Oh now I see: testrunner does seem to load the plugin, it was just Minibrowser that didn't find the plugin without tricks... I debugged this a bit, will document here so I remember this on monday. 

This is what the ObjectsAreSame fumction looks like when running:
(gdb) list
1031	static bool objectsAreSame(PluginObject* obj, const NPVariant* args, uint32_t argCount, NPVariant* result)
1032	{
1033	    if (argCount != 2 || !NPVARIANT_IS_OBJECT(args[0]) || !NPVARIANT_IS_OBJECT(args[1]))
1034	        return false;
1035	
1036	    BOOLEAN_TO_NPVARIANT(NPVARIANT_TO_OBJECT(args[0]) == NPVARIANT_TO_OBJECT(args[1]), *result);
1037	    return true;
1038	}
1039	
1040	static bool pluginInvoke(NPObject* header, NPIdentifier name, const NPVariant* args, uint32_t argCount, NPVariant* result)
(gdb) print args[0].value.objectValue
$31 = (NPObject *) 0x465590
(gdb) print args[1].value.objectValue
$30 = (NPObject *) 0x465420


So the values are indeed different. A little up the stack: 


(gdb) frame 2
#2  0x00007ffff765d1ab in WebKit::NPObjectMessageReceiver::invoke (this=0x4650b0, 
    methodNameData=..., argumentsData=WTF::Vector of length 2, capacity 2 = {...}, 
    returnValue=@0x7fffffffdce0: 96, resultData=...)
    at /home/jku/intel/src/WebKit/Source/WebKit2/Shared/Plugins/NPObjectMessageReceiver.cpp:88
88	    returnValue = m_npObject->_class->invoke(m_npObject, methodNameData.createNPIdentifier(), arguments.data(), arguments.size(), &result);
(gdb) print argumentsData
$36 = WTF::Vector of length 2, capacity 2 = {{m_type = 7, m_boolValue = false, 
    m_int32Value = 0, m_doubleValue = 0, 
    m_stringValue = <error reading variable: Cannot access memory at address 0x8>, 
    m_localNPObjectIDValue = 0, m_remoteNPObjectIDValue = 2}, {m_type = 7, 
    m_boolValue = false, m_int32Value = 0, m_doubleValue = 0, 
    m_stringValue = <error reading variable: Cannot access memory at address 0x8>, 
    m_localNPObjectIDValue = 0, m_remoteNPObjectIDValue = 3}}

[Jussi Kukkonen (jku)]

While I still remember: I don't think this is EFL or WTR related. The plugin ipc implementation (on WK2) just does not seem to support this at the moment: when objects are added as arguments on the web process side, nothing checks if they happen to be the same ones. Likewise on the plugin side: there's no code to make sure objects with same remote id would point to the same local object.

[Michael Catanzaro]

Closing this bug because the EFL port has been removed from trunk.

If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.