194283 - [AxPlugin] Support myControl.object notation

Status: RESOLVED INVALID

(Core Graveyard :: Embedding: APIs, defect)

Description

[Adam Lock]

Sites such as ESPN use this notation to test if an embedded object has been created:

<OBJECT id="myControl" CLASSID="CLSID:......."></OBJECT>
<script>
if (document.myControl.object)
  alert("Hooray I have an object");
else
  alert("Boo, no object!");
</script>

COM Connect / Plugin should probably support the same, i.e. asking for the
object property returns the object that the OBJECT tag instantiates.

http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/object.asp

Comment 1

[Charles Rosendahl]

[AxPlugin] -> Ashish

Comment 2

[Adam Lock]

-> David

Comment 3

[Adam Lock]

May also be required for namespace conflicts. e.g. the contained object has a
classid property in which case the .object notation might be employed to resolve
the ambiguity:

document.foo.classid; // classid property of the OBJECT tag
document.foo.object.classid; // classid property of the contained object

Also of course:

document.foo.object; // Returns the contained object 
document.foo.object.object; // Returns the object property of the contained object

If there is no contained object, then document.foo.object should do what IE does
which is return null

Comment 4

[David Bradley]

Patch coming soon

Comment 5

[David Bradley]

Attachment: Patch to add .object support

Ok, this turned out to be more trouble than I expected. Both ideas I had in
mind had problems with security and other infrastructure. Basically the easy
approach worked against too many existing structures.

This patch basically resolves the property .object on IDispatch wrapper. I
factored out some of the XPCIDispatchExtension::DefineProperty since this would
be the third copy of some code. And further factored out code in
XPCDispInterface::Member::GetValue into XPCDispObject::NewJSFunctionObject so I
could reuse that code in XPCIDispatchExtension::DefineProperty

The patch builds a normal function object with a special callback to server as
the getter when the object property is requested. The key is the special
callback that just returns the object passed in.

About the only issue with this code, is that it rebuilds the function object
each time, unlike how the normal path reuses the function object for an
interface method. I'm sure this is probably a worth while optimization, but I
think for now, its good enough to get this working. Keeping this function
object for reusing isn't hard, but it's not trivial either.

Comment 6

[David Bradley]

Comment on attachment 121249 [details] [diff] [review]
Patch to add .object support

Looking for reviews, see previous comment for a summary of what this patch
does.

Comment 7

[Adam Lock]

Comment on attachment 121249 [details] [diff] [review]
Patch to add .object support

Need to produce a test harness to ensure the behaviour for

document.foo.object & document.foo.object.object corresponds to the behaviour
in IE

Comment 8

[Adam Lock]

Attachment: Test harness

This is a simple control with "object" and "width" properties and a
NamespaceTestCtl.htm test harness. The test harness sees what happens when
testing for document.foo.object, document.foo.object.object, document.width,
document.object.width.

It also applies similar tests to see what happens with new ActiveXObject() and
for a control which doesn't exist.

Page loading should display pass codes for the tests

Comment 9

[David Bradley]

Moving out, this is going to take a bit more effort as my implementation turned
out to be too simple to mimic IE's behavior.

Comment 10

[David Bradley]

From the behavior I'm seeing it looks like the OBJECT tag needs to create a
separate object, that has the ActiveX object as a prototype. Then assign
whatever properties are specified, plus add the "object" property referring back
to its prototype. So it looks like this isn't an XPConnect issue at all.

Comment 11

[David Bradley]

Who can we assign this too? I'm not that familiar with the code, I'm willing to
try and tackle it, but it will take me longer than someone who's familiar with
it. I think  the place to start is nsObjectFrame.cpp, but not positive. Looks
like Peter L has touched the file the most.

To recap, what we need to do is have the object tag instantiate the control, and
then create a new JS object that has the control as its prototype. Then make any
property assignments necessary to the object, like the width/height in the test
harness.

Adam, what I'm not sure of is, if border and ID, are they special, or the same
as width and height, as far as how they are used.

Comment 12

[Peter Lubczynski]

Is this limited to Active-X or will other plugins use this too?

Comment 13

[David Bradley]

(I thought I commented, but apparently not) I'm not positive, but I suspect it's
only ActiveX. Adam, do you know of any other plugins that would make use of this?

Comment 14

[Adam Lock]

It's ActiveX specific behaviour, though I guess it might be of use for plugins too.

Comment 15

[David Bradley]

Started looking at this again. There are five attributes, but IE only reflects
three of the five. ID and CLASSID are not reflected. What I'm trying to figure
out is are there any more that should be ignored, or can I just hardcode
ignoring of ID and CLASSID and reflect the rest?

Comment 16

[David Bradley]

Moving out, speak up if you believe this needs to be considered for 1.5b

Comment 17

[David Bradley]

Moving out

Comment 18

[Ed Morley [:emorley]]

The ActiveX embedding API was removed in bug 662023 and friends.

-> INVALID

[Filter bugspam on activexinvalid]