145119 - OBJECT tag doesn't work right

Status: RESOLVED INVALID

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

Description

[shrirang khanzode]

realOne installed.

this test does not load in pr1 0512..but works on 4.79

Comment 1

[serge (gone)]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512
RealPlayer(tm) G2 LiveConnect-Enabled Plug-In (32-bit) ver. 6.0.8.1024
components\nppl3260.dll & nppl3260.xpt automatically installed into components 
folder by netscape installer.
Probably for any other non xpcom plugins we won't be able to handle such king of 
object tag properly.
Investigating...

Comment 2

[av (gone)]

Does not work for me neither on the trunk (Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.0.0+) Gecko/20020516) nor on the branch (Mozilla/5.0 (Windows;
U; Windows NT 5.1; en-US; rv:1.0rc3) Gecko/20020516). The same plugin.

Comment 3

[av (gone)]

This kind of <object> tag syntax is supposed to be fully supported, it is just
parsed by our code exactly like <embed> tag, if fact, it is the same code.

Comment 4

[serge (gone)]

>The same plugin
are you talking about realOne or RealPlayer8?
realOne claims to handle "*" mimetype, the test case has 
TYPE="audio/x-pn-realaudio-plugin"
how we suppose to bind this type with realOne?
>it is just parsed by our code exactly like <embed> tag
well, it doesn't seem like exactly:(
I'll post two simple test cases to proof it.

Comment 5

[serge (gone)]

Attachment: test case with unknown mimetype TYPE="something-foo"

it has two tags with the same attributes
EMBED  with type="application/x-shockwave-flash-foo"
OBJECT with type="application/x-shockwave-flash-foo"
but no default plugin involved on OBJECT tag.

Comment 6

[serge (gone)]

6.0 behaves in the same way, it shows only 1 puzzle on embed tag,
4.79 shows 2 puzzle icons.

Comment 7

[av (gone)]

I mean 6.0.8.1024 thing, and the player itself is RealPlayer 8, build 6.0.9.584.

The only difference in parsing which I see looking at the code is expecting DATA
for <object> and SRC for <embed>. Everything should be in nsIPluginTagInfo which
ends up in nsPluginInstanceOwner, which in turn should not in theory care much
about  which tag it is. If it is not the same for the two tags, we should
probably file a bug.

Comment 8

[av (gone)]

Well, 'no default plugin on <object> tag' is not what I am talking about. I
meant parsing the tag parameters which should not differ. All the attributes are
supposed to be passed to the plugin instance via NPP_New regardless of the tag.

And yes, we don't display the default plugin on <object> tag because according
to the HTML we were supposed to show the tag content instead, so there is
explicit check for the tag after failing to instantiate a plugin instance. Looks
like we will need to change this behaviour though along the lines of recent
discussions, and if I remember correctly we have a bug on that.

Comment 9

[serge (gone)]

well, the test case (attachment 83996 [details]) is really belongs to bug 134445,
and this bug is probably a dup of 134445.
does your real8 work with embed tag?
http://www.mozilla.org/quality/browser/front-end/testcases/plugins/ra1.html

Comment 10

[av (gone)]

It looks really strange. The execution goes through the part of the code which
creates a wrapper as if this is a legacy plugin, although no wrapper is created
and no our NPP_* functions are called. I am wondering if we are doing right
thing with the factory we get from the plugin, because we the creation of the
xpcom plugin instance by the component manager fails with 'not registered' error
and we use the factory to create the instance. I think the problem is that we
don't pass the DATA attribute as we should, that's why it does not play.

Serge, in your working build, can you step through
|nsPluginHostImpl::TrySetUpPluginInstance| and see what is happening?

Comment 11

[Peter Lubczynski]

Yes, it's my bug 134445. I think the way to go there may be just to add a check
if 'codebase' has something in it and then show the default plugin. I believe
the Windows version already has code to read this.

This bug is very strange. Same testcase, but the one with object fails:
embed: http://panther.mcom.com/testcases/plugins/testcases/real1.html
object: http://www.mozilla.org/quality/browser/front-end/testcases/plugins/ra8.html

Why does the embed work and the object fail?

RealPlayer does show up for me, it just doesn't play anything when the play
button is clicked with the object tag. I get Polish Radio with the embed tag. :)

Are we using the tag wrong?
Does RealPlayer simply not support this in the their plugin?
Is there a bug in our code?

Comment 12

[Peter Lubczynski]

Andrei, setting breakpoints in nsPluginStreamListenerPeer::OnStartRequest and
nsPluginStreamListenerPeer::OnDataAvailable. I see we are feeding something to
the plugin.

Comment 13

[av (gone)]

Yes, it works for me with <embed> but does not if I change <embed> to
<object></object> and SRC to DATA.

Comment 14

[av (gone)]

Peter, I would say that Real fails to look for DATA and only looks for SRC, but
Serge sees it working with older versions of Mozilla, so the problem is probably
ours.

Comment 15

[serge (gone)]

when did I say that?
real isn't using  NPN_GetURL call to get content, it's doing its own connection.

Comment 16

[av (gone)]

Ah, I thought your WFM in comment #1 meant that. Sorry.

Comment 17

[Peter Lubczynski]

Andrei, you are right!

This is not our bug. Real is looking for the SRC= attribute and there is nothing
we can do about it. If you change the testcase to:
OBJECT data="http://www.wrn.org/audio/0000.ram"
       src="http://www.wrn.org/audio/0000.ram"

It works!

--->INVALID

Comment 18

[Peter Lubczynski]

Attachment: testcase showing Real working with OBJECT tag

This shows that Real needs BOTH the SRC and DATA attribute to work with us in
the OBJECT tag. We follow the spec and use the DATA attribute and feed the
plugin the stream but Real will not play it unless there is ALSO a SRC
attribute.

Comment 19

[serge (gone)]

Thanks Peter, but I think shrir filed this bug for realOne not for real8.
Shrir could you clarify please?

Comment 20

[av (gone)]

Ah. We don't set up an initial stream if we have no DATA attribute in the object
tag. So we need to have it just to set up a stream in our code, but we also need
to have SRC in order to work around Real bug, that's why we need both. We can
easily fix this to be able to use SRC only (this is in
|nsPluginHostImpl::InstantiateEmbededPlugin|):

    if(pti) {
      const char *value;
      if(tagType == nsPluginTagType_Embed)
        havedata = NS_SUCCEEDED(pti->GetAttribute("SRC", &value));
-     if(tagType == nsPluginTagType_Object) 
+     if(tagType == nsPluginTagType_Object) {
        havedata = NS_SUCCEEDED(pti->GetAttribute("DATA", &value));
+       if (!havedata) // try SRC
+         havedata = NS_SUCCEEDED(pti->GetAttribute("SRC", &value));
+     }
    }

    if(havedata && !isJava && bCanHandleInternally)
      rv = NewEmbededPluginStream(aURL, aOwner, instance);

But I am not sure we want it. The original test case will still not work due to
the Real bug.

Comment 21

[shrirang khanzode]

serge, the new testcase peter posted works on realOne. 

Comment 22

[serge (gone)]

av is right, we can do this workaround for real, 
but I doubt there are any content with such king of non standard attribute of 
object tag.
shrir, please be more specific on test cases, your initial 
>this test does not load in pr1 0512..but works on 4.79
I understood as we do not load the real plugin at all, not that  real does not 
load its stream url,
and this is why in comment #1 I said WFM

Comment 23

[shrirang khanzode]

no..in my initial case , I meant to say "we don't stream". realplayer loads fine 
but nothing plays. sorry for confusing u.