636446 - Typeof some_silverlight_object.Content returns "function", instead of object

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Denis]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11

MS Silverlight objects provides scriptable Content property (not a function).
When trying to get its typeof in JavaScript code Firefox 4.0b11 returns "function" while Firefox 3.6.13 returns "Content" and other browsers returns "object".

Reproducible: Always

Steps to Reproduce:
1. go to www.silverlight.net or any other site with Silverlight movie on it
2. in the url bar enter the following line of code:
javascript:alert(typeof document.getElementsByTagName("OBJECT")[0].Content)

Actual Results:  
Firefox 4.0b11 shows alert stating "function"

Expected Results:  
Firefox 4.0b11 shows alert stating "object" or at least "Content"

Comment 1

[Ed Morley [:emorley]]

No idea if this was intentional or not, but perhaps the easiest way to answer would be if you could find a regression range please:
http://harthur.github.com/mozregression/

Comment 2

[Denis]

2010-02-25-03-mozilla-central build returns "function" while
2010-02-24-06-mozilla-central build returns "object"

Correction to bug description: Firefox 3.6.13 returns "object" (not "Content").

Comment 3

[Ed Morley [:emorley]]

Confirmed using Silverlight 4.0.60129.0 and Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre ID:20110222191848

Thanks for the range - I've looked up the revision IDs (since they are more accurate than the dates), which give the following pushlog on m-c:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ddfecbc93934&tochange=a29d44f196a6

This range, whilst only 24 hrs, includes a lot of changesets, since it has a few big TM merges in the middle.

As such, I found the range on TM in case it helps:

Last good nightly: 2010-02-22 
First bad nightly: 2010-02-23

Pushlog: http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=110112bebb00&tochange=dca026286095

Possible cause (though there are still a lot of changesets in that range)...
Bug 547314 - Introduce ObjectOps for typeof

Also, this issue sounds similar to what happened in bug 553407, which leads me to think this is indeed the changeset that caused the problem.

Not sure whether this should block or not, nominating so it doesn't get missed / someone else can make the call.

Comment 4

[Andreas Gal :gal]

I get "Error calling method on NPObject!" when I try to call Content.

Comment 5

[Benjamin Smedberg]

It's an object, you can't call it. But we really don't know that until you try, given the way npruntime typically works. This is the JSClass we use for all NPObjects (objects or potential functions):

http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsJSNPRuntime.cpp#183

I think that we should probably make all NPObjects be typeof "object", but it doesn't sound serious enough to block. Denis, how did you find this bug, and does it affect something important in production?

Comment 6

[Denis]

Ed, it seems that you are absolutely right - this pushlog contains new function jsobj::js_TypeOf with the following comment: 'ECMA 262, 11.4.3 says that any native object that implements [[Call]] should be of type "function".'

Benjamin, sorry, I can't tell you how I found this bug, but I found a workaround, so this bug is not serious to me.

Comment 7

[Benjamin Smedberg]

It's possible that we should have a separate JSClass for NPClasses which implement NPClass.invokeDefault and those which don't. Or is it possible with the same NPClass for the engine to ask per-object whether something implements [[Call]] or not?

I can bring this up with plugin-futures also.

Anyway, I don't think this needs to block, it seems pretty edge-case to me.

Comment 8

[Brendan Eich [:brendan]]

(In reply to comment #6)
> Ed, it seems that you are absolutely right - this pushlog contains new function
> jsobj::js_TypeOf with the following comment: 'ECMA 262, 11.4.3 says that any
> native object that implements [[Call]] should be of type "function".'

The ECMA-262 spec defines *all* "native objects", so a plugin object can't be one. It is an example of what ECMA-262 calls a "host object" and host objects with [[Call]] internal method *may or may not* report typeof "function". So there is no ECMA-262 spec requirement here.

What do other browsers do?

/be

Comment 9

[Jan de Mooij [:jandem]]

Chrome and Opera alert "object" for the steps in comment 1. 

Is this bug 268945?

Comment 10

[Andreas Gal :gal]

Attachment: patch

Untested.

Comment 11

[Andreas Gal :gal]

This patch splits the JSClass into two. I also found two stray JSAutoRequests. One is unnecessary, the other one is in the wrong spot. Entering a request without entering a compartment is bad.

Comment 12

[Andreas Gal :gal]

Attachment: patch

Building.

Comment 13

[Andreas Gal :gal]

Attachment: patch

Comment 14

[Benjamin Smedberg]

This isn't going to work without some more mechanics, because the OOPP intermediate layer always has an invokeDefault/construct function pointer.

If Jan is right, is there a way to get typeof "object" even for objects which implement call in their JSClass?

Comment 15

[Andreas Gal :gal]

Not as long these objects are native.

JSType
js_TypeOf(JSContext *cx, JSObject *obj)
{
    /*                                                                                                                                                               
     * ECMA 262, 11.4.3 says that any native object that implements                                                                                                  
     * [[Call]] should be of type "function". However, RegExp is of                                                                                                  
     * type "object", not "function", for Web compatibility.                                                                                                         
     */
    if (obj->isCallable()) {
        return (obj->getClass() != &js_RegExpClass)
               ? JSTYPE_FUNCTION
               : JSTYPE_OBJECT;
    }

    return JSTYPE_OBJECT;
}

Comment 16

[Andreas Gal :gal]

Here is the definition of isCallable(), btw:

inline bool
JSObject::isCallable()
{
    return isFunction() || getClass()->call;
}

Comment 17

[Brendan Eich [:brendan]]

Comment 16 + comment 15 show that we've lost the ability to have callable "host objects" whose typeof-type is "object". That seems like a regression, although in an ideal world there wouldn't be host objects, or callable host non-functions at least. In reality we have them, and so do other browsers.

So what does typeof document.all in a quirks-mode document say?

/be

Comment 18

[Andreas Gal :gal]

I don't think we lost that ability. Native objects lost that ability. Non-native host objects can overwrite the typeOf hook and provide any behavior they desire.

Comment 19

[Henry Jen]

Attachment: Test case for Java types

Comment 20

[Henry Jen]

Same issue applies to Java, the type returned for attached test case are object in FF 3.6.x, but are function in FF 4.

Comment 21

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/