536116 - TypeError invoking plugin-unique method on plugin object

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Elliot Block]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b6pre) Gecko/20091220 Firefox Namoroka/3.6b4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b6pre) Gecko/20091220 Firefox Namoroka/3.6b4pre

When you get an object back from document.getElementByID, if that object is a plugin, you should be able to call its unique plugin methods.

With this bug, attempting to invoke a plugin-unique method (as opposed to the methods are common to general objects/elements) results in a TypeError.

Reproducible: Always

Steps to Reproduce:
pluginObj = document.getElementById(pluginId);

Then you call a plugin method.  For example, for Silverlight, you should be able to call:

var result = plugin.isVersionSupported("3.0.40818.0");


For some reason does NOT repro with Error Console open.

This works fine in 2009-07-11-03-tracemonkey build.
This does not work in 2009-07-12-03-tracemonkey build. 

So presumably whatever broke this was added in between those two builds.
Actual Results:  
TypeError: [method] (in the example, isVersionSupported) is not a function

Expected Results:  
Should successfully detect and invoke the function.

Comment 1

[Elliot Block]

Attachment: Test page to repro bug in affected builds

This is a test page that will repro the bug if the build is affected. 

E.g. the operation works in 2009-07-11-03-tracemonkey
But does not work in 2009-07-12-03-tracemonkey

Comment 2

[Johnny Stenback (:jst)]

Sure enough, this is a regression. I tracked this down to the regression range 2009-07-06-04 to 2009-07-07-04 on mozilla-central, which makes the fix for bug 502137 the likely cause for this. I'm testing out a fix on try server right now (not equipped to debug locally right now), and I'll let you know what I find.

Comment 3

[Johnny Stenback (:jst)]

... and I forgot to thank Elliot for the tracemonkey regression rate which made finding the likely source for this much easier. The tracemonkey regression range contained a mozilla-central merge, which contained the fix for bug 502137, and searching around that date on mozilla-central pointed me at the right date on first test.

And I think this should block, and I've marked it as such, but others feel free to change that status if you disagree.

Comment 4

[Johnny Stenback (:jst)]

Oh, and interestingly enough, if I save the testcase locally, the bug does not reproduce, but it does when loading it from bugzilla.

Comment 5

[Johnny Stenback (:jst)]

Attachment: fix v1.0

This patch fixes this bug. The problem was that the deadcode removal that was done in bug 502137 removed a bit too much. This patch restores the necessary parts.

https://build.mozilla.org/tryserver-builds/[e-mail]-plugin-fix-test2/ has try server builds with this fix.

Merry Christmas :)

Comment 6

[Josh Aas]

Comment on attachment 419142 [details] [diff] [review]
fix v1.0

Merry Christmas indeed! Looks good to me, thanks Johnny.

I was able to repro and test the fix on Mac OS X 10.6 with Silverlight 3.0.40818.0.

Comment 7

[Josh Aas]

I pushed this to mozilla-central to get the ball rolling.

http://hg.mozilla.org/mozilla-central/rev/2167c7a6f65b

Comment 8

[Josh Aas]

The 1.9.2 branch patch might not be so simple because we restored OJI/XPCOM plugins there on Mac OS X. I'm looking at what we need to do but I need to wait for my 1.9.2 build to finish.

Comment 9

[Josh Aas]

Attachment: fix v1.0 - 1.9.2 version

This is a direct port of jst's fix to the 1.9.2 branch but like I said, I am not sure this is enough there. We need to make sure this won't break JEP on Mac OS X.

Comment 10

[Josh Aas]

We probably want to more or less back out bug 502137 on the 1.9.2 branch but I don't know jsapi and wrappers well enough to do that with confidence in the time that I have left for work while I'm on vacation.

I'm not sure what will happen to the JEP if we just land the fix we landed on trunk so I'm going to hold off on landing it there for now.

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 419171 [details] [diff] [review]
fix v1.0 - 1.9.2 version

The code that got removed in bug 502137 that's not restored by this patch only has an impact on XPCOM plugins or NPAPI plugins that expose scriptable XPCOM interfaces, none of which we support in 3.6, so I think we should take this on the branch rather than backing out the fix for bug 502137 wholesale.

Comment 12

[Josh Aas]

Pushed to mozilla-1.9.2

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/23054aa8df66

I'd still like to have smichaud look at the impact for JEP in case there is any. I don't know how JEP exposes its scripting interface.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

So for now this patch has also fixed the problem with Google Video and Voice on Gmail on trunk and 1.9.2 which has been reported as bug 524649. Thanks!

Comment 15

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to comment #12)
> Pushed to mozilla-1.9.2
> 
> http://hg.mozilla.org/releases/mozilla-1.9.2/rev/23054aa8df66

Can this now be marked with status-1.9.2: final-fixed ?

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #15)
> Can this now be marked with status-1.9.2: final-fixed ?

It has been pushed to 1.9.2 so we should mark it as final-fixed, yes. Verification awaiting from Steven...

Comment 17

[Josh Aas]

I was waiting for tbox to clear before marking 1.9.2 fixed, everything went green though so we're good.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

I'll test the JEP with the patch as soon as I have time (probably
later this week).  But I strongly suspect the JEP won't have any
problems with it.

I frankly wasn't aware the JEP has any scripting interface aside from
LiveConnect :-)  Whatever it does have must be implemented in the
JEP's MRJPlugin.plugin (adapted from the old MRJ Carbon plugin).

I'll run up some tests using the information from comment #0.  But I
suspect my tests will always fail, with or without this patch.

Comment 19

[Andy Rivas]

Hey Steven,

Can you try this page?  Are we seeing the same bug?

1. http://shop.abc.net.au/browse/product.asp?productid=763600
2. click "Preview" button

Can you interact with the control?

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2)
Gecko/20100105 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2)
Gecko/20100105 Firefox/3.6 (.NET CLR 3.5.30729)

Comment 20

[Steven Michaud [:smichaud] (Retired)]

Hi, Andy.

Are you sure you didn't comment accidentally in the wrong bug? :-)

In any case, I tried your testcase on OS X 10.6.2 and 10.5.8, in FF
3.5.7 and in a recent FF 3.6 nightly -- I had no trouble in any of
them.

I moused over the control, and tried pressing the play/pause and
full-screen buttons.  Everything worked as you'd expect.

My only problem was that the control takes 15-20 seconds to appear,
with no visual clue as to what's going on.