382378 - Minefield: JS calls on JS-built flash-object fail [JavaScript Flash ExternalInterface]

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Jaroslav Zaruba]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070527 Minefield/3.0a5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070527 Minefield/3.0a5pre

When a flash-object is created by static-markup JS calls work fine.
When it is built dynamically (JS + DOM-manipulation) JS calls on the flash-object fail whilst Flash->JS calls seem to work fine.
The test-case: http://bugs.sounds4u.net/Minefield/ExternalInterface/
(In FF2 everything works fine.)

Reproducible: Always

Steps to Reproduce:
1. using JS and DOM-API create a flash-object with some ExternalInterface functions
2. make a JS call on the flash-object
Actual Results:  
the flash ExternalInterface functions are not available so the JS-call ends up with an error

Expected Results:  
the flash functions exposed using ExternalInterface should work regardless whether the object has been spawned by a static markup or using JS + DOM-manipulation

Comment 1

[Jaroslav Zaruba]

Attachment: test-case (probably must be accessed through a webserver)

contains XHTML-document, SWF file with an audioPlayer and 62kB mp3-sample

Comment 2

[Ria Klaassen (not reading all bugmail)]

Jaroslav, your testcase doesn't seem to work, when I run it from my desktop. But I was able to reproduce the problem with the link you gave. Because it once worked as expected this could be a regression.
Regression range for this is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2005-09-21+09%3A00&maxdate=2005-09-22+00%3A00
Putting some people on the CC list (hopefully the right one is amongst them).

Comment 3

[:Gavin Sharp [email: [e-mail]]]

In that range, bug 1156 or bug 309534 are the most likely culprits, I think.

Comment 4

[Jaroslav Zaruba]

> Jaroslav, your testcase doesn't seem to work, when I run it from my desktop.

I do apologize; I guess it must be accessed through a webserver (be it localhost or not), mea culpa.
But it doesn't matter as long as the URL works.

Comment 5

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #3)
> In that range, bug 1156 or bug 309534 are the most likely culprits, I think.
>
OK thanks :) 

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Actually, I should have probably looked at the actual patch before making that comment, rather than just the list of files - I think the patch for bug 309534 is pretty unlikely to have caused something like this.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Bug 1156 could lead to something like this, in theory...  Shouldn't have, though.

In any case, this being broken should block 1.9, in my opinion. Given that Ria can reproduce, confirming.  What version of Flash is having the problem?  Flash 9?  Or Flash 7?

Comment 8

[Jaroslav Zaruba]

> What version of Flash is having the problem? Flash 9? Or Flash 7?

Flash 9: yes (bug occurs)
Flash 7: I don't know

Comment 9

[Boris Zbarsky [:bzbarsky]]

biesi, do you have time to look into this?

Comment 10

[Ria Klaassen (not reading all bugmail)]

Problem is also present with Flash 8.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Biesi, please have a look at this regression to see if it's from any of your patches.

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

The plugin gets instantiated by onStartRequest, so we have to call this afterwards (note: the channel version of nsObjectFrame::Instantiate doesn't call this, although adding it there doesn't make a difference of course)

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

I'll add a comment to the TryNotifyContentObjectWrapper call:

  // We have to notify the wrapper here instead of right after Instantiate
  // because the plugin only gets instantiated by onStartRequest, not by
  // Instantiate.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 274884 [details] [diff] [review]
patch

>Index: content/base/src/nsObjectLoadingContent.cpp
>+    } else if (mType == eType_Plugin) {

Add a comment here that calling OnStartRequest on the listener may have instantiated the plugin?  Though really, I would prefer this call happen in whatever code actually does the instantiation....

>+        frame->TrYNotifyContentObjectWrapper();

Lowercase "y"?

r+sr=bzbarsky, but again I'd prefer to put this code elsewhere.

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: merged to trunk, comment addressed

There doesn't really seem to be a good place... the plugin stream listener peer isn't ideal either.

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in content/base/src/nsObjectLoadingContent.cpp;
/cvsroot/mozilla/content/base/src/nsObjectLoadingContent.cpp,v  <--  nsObjectLoadingContent.cpp
new revision: 1.56; previous revision: 1.55
done
Checking in layout/generic/nsIObjectFrame.h;
/cvsroot/mozilla/layout/generic/nsIObjectFrame.h,v  <--  nsIObjectFrame.h
new revision: 1.13; previous revision: 1.12
done
Checking in layout/generic/nsObjectFrame.cpp;
/cvsroot/mozilla/layout/generic/nsObjectFrame.cpp,v  <--  nsObjectFrame.cpp
new revision: 1.610; previous revision: 1.609
done
Checking in layout/generic/nsObjectFrame.h;
/cvsroot/mozilla/layout/generic/nsObjectFrame.h,v  <--  nsObjectFrame.h
new revision: 1.68; previous revision: 1.67
done