15887 - JSObject setSlot() can't set an indexed member.

Status: VERIFIED INVALID

(Core Graveyard :: Java: OJI, defect, P3)

Description

[Leila Garin]

Using 09/23/99 Mark Lin's Mozilla and MRJPlugin092499 build.

To reproduce,
- Load
http://lonely/blackwood_qa/src/OJI/PluginTest/sunw/LiveConnect/html/LCJavaToJS.html.
- Click on the Test Link for JSObject's setSlot method.
  This test is supposed to set/create a new image object to the ImageArray.
  But it didn't that's why accessing the supposedly new slot returns
  a NullPointerException.

Comment 1

[drapeau]

Again, is this bug really happening only on the Macintosh, or is it also
happening on Win32?  Thank you, Leila, for reporting this and thanks in advance
for the extra platform info.

Comment 2

[Leila Garin]

This bug also happens on WinNT using 10/11/99 Mozilla build and
jdk1.3 early access release.

Comment 3

[drapeau]

Setting "Platform" and "OS" to "All" since if the bug happens on both Mac and
Windows, it's likely to be on all platforms.  Then again, I could be right.

Comment 4

[Jeff Dyer]

Leila,
Could you attach the test case. The url referenced is not publically accessible.
Thanks.

Comment 5

[Leila Garin]

Attachment: LiveConnect Java to JavaScript tests.

Comment 6

[Leila Garin]

Attachment: contains html, class, src of LiveConnect test.

Comment 7

[Jeff Dyer]

Here's my analysis of this bug.

The test fails because the nsJSUtils::nsCallJSScriptObjectSetProperty is unable
to get the nsIJSScriptObject interface it needs to complete the operation.

The object passed into nsJSUtils::nsCallJSScriptObjectSetProperty is an
nsContentList, which is-a nsIDOMHTMLCollection. This appears to be as it should.
The call stack looks like this:

nsJSUtils::nsCallJSScriptObjectSetProperty
SetHTMLCollectionProperty
js_SetProperty
JS_SetElement
nsCLiveConnect::SetSlot
.
.
.
Java_sun_plugin_javascript_navig5_JSObject_JSObjectSetSlot
.
.
.


[Thinking out loud for a moment] Possible points of failure are:

a. The base of the call tree (e.g.
Java_sun_plugin_javascript_navig5_JSObject_JSObjectCall(…) should be providing
another object as the receiver object.
b. nsJSUtils::nsCallJSScriptObjectSetProperty should  be asking for the
nsIScriptObjectOwner before it asks for the nsIJSScriptObject.
c. nsContentList should implement nsIJSScriptObject directly.
d. None of the above.

I think the answer is c. nsContentList should implement nsIJSScriptObject as
do the other DOM components (e.g. nsIDOMWindow). In fact all of the slot
operations in this test fail for this same reason (see Bug 15888), the receiver
object (an nsContentList) is not a nsIJSScriptObject.

It would be good to get someone familiar with the implementation of XPCOM in on
this one.

Comment 8

[drapeau]

Copying DOM, JavaScript, and XPCOM module owners in a desperate plea for help.
Maybe one of them will be able to confirm what Jeff is saying here.

Comment 9

[Mike McCabe]

Adding fur to the CC dogpile in hopes of liveconnect wisdom.

Comment 10

[drapeau]

Adding Norris Boyd to the CC list as well; perhaps he can contribute something
here?

Comment 11

[vidur (gone)]

I believe the test should be modified. The images array is not an editable array
per the DOM spec (or 4.x documentation), so I don't believe setting indexed
properties on it should work. Jeff believes that this is sometimes done (as
means, for example, of caching newly created images) and the fact that it
doesn't work represents a regression.

In either case, the test should be modified to set an indexed property on some
object (say the document) that isn't otherwise indexable. Feel free to open a
bug on me describing the regression noted above (though I'll probably put it
relatively low on my priority list).

Comment 12

[drapeau]

I'm closing out this bug as invalid; thank you very much, Vidur (and you too,
Jeff Dyer), for rescuing this bug with your comments.
I will file a new bug on the regression that Vidur mentions, understanding that
it may turn out to be a low priority item.