54437 - realplayer does not load as embedded plugin in some cases (MIME problems?)

Status: VERIFIED FIXED

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

Description

[shrirang khanzode]

build:2000092711 branch
plugin: realplayer G2

Steps:
1 Go to the url above
2 Click on any of the links under the title "Video Headlines"
3 Observe a javascript window open up with the puzzle icon in place of   
  realplayer  
4 Clicking on it to get the plugin does not do anything but clicking on the link 
  saying "Click here if your version of RealPlayer doesn't work with these media 
  files." works fine and launches realplayer as a helper app.
5 This works fine in 4.x browser.

Comment 1

[shrirang khanzode]

cc :ekrock. This bug was found using testcase suite from real.

Comment 2

[ekrock's old account (dead)]

Marking P1 because high profile partner (Real) and web site (ABCNews.com) and 
high profile backward compatibility. Marking 4xp and top100. Nominating for rtm 
as correctness bug.

Comment 3

[Ari Pollak]

Not sure if this is the same bug, but after downloading RealPlayer for Linux,
and copying the plugin (rpnp.so & raclass.zip) to the plugins/ directory in the
Mozilla distribution, going to about:plugins does not show RealPlayer plug-in in
the list.

Comment 4

[ekrock's old account (dead)]

Ari, thanks for the info. However, that's probably the known problem that legacy
Nav4 Linux plug-in binaries don't work in Moz/N6 for Linux due to the
Motif-to-GTK switchover. See http://www.mozilla.org/docs/plugin.html for more
info about that.

Comment 5

[Manoj Mehta]

This is what happens on Windows 98 also. I have copied the dump of the stack and
will add it to this comment:

Unhandled exception in Mozilla
----------------------------------
MOZILLA caused an invalid page fault in
module NECKO.DLL at 0187:6067f3e5.
Registers:
EAX=020f4810 CS=0187 EIP=6067f3e5 EFLGS=00010202
EBX=020f4814 SS=018f ESP=0068fa24 EBP=0068fa3c
ECX=020f5264 DS=018f ESI=00000000 FS=1977
EDX=0068fa38 ES=018f EDI=020f5260 GS=0000
Bytes at CS:EIP:
8b 06 ff 50 70 8b 07 57 ff 50 08 33 c0 5f 5e 5b
Stack dump:
00000000 020f4814 00000000 0208d180 0208d190 00000002 0068fa74 6067efb7 0208d180
0225fc40 6068b640 60d17638 020dd784 0068fa70 60d17638 020dd784

A test URL is

,
http://209.207.247.131/cgi-bin/tssongs/load.cgi?f=taal/ishq_bina.rm&l=4&i=364&m=121&d=1

Comment 6

[R.K.Aa.]

Ari Pollak: See bug 56464. Most aren't able to make it work, and yet - there's
Pavlov's screenshot, the proof that it's possible.

Comment 7

[ekrock's old account (dead)]

This is the URL of the launch page to bring up the window:
http://abcnews.go.com/sections/us/video_index/video_index.html

The actual URL of the launched page that shows the problem:
http://abcnews.go.com/sections/world/MP/001016findlay_video_mp.html

Changing URL from launcher page to launched page since that's what shows the
problem. Marking qawanted. Will try to create simplified test case. Part we
don't understand is: why is the browser not detecting RealPlayer plug-in in a
window whose content was dynamically written by JavaScript?

vidur, jst, heikki -- Any ideas?

Marking [rtm need info]. Reassigning to attinasi.

Comment 8

[Marc Attinasi]

I don;t think it has anything to do with the window being created by script. I
have created a static page with the same embed tag used in the
javascript-generated content and I see the same problem, the 'click here to get
the plugin' puzzle-piece, and it doesn't work. I'm still investigating it...

I'll attach the testcase.

Comment 9

[Marc Attinasi]

Attachment: Testcase: static page with same problem, i.e. embed tag not working for real player.

Comment 10

[Marc Attinasi]

Attachment: Testcase: showing side-by-side embed elements with different src=content; one works one does not

Comment 11

[Marc Attinasi]

Another note: I added the TYPE="audio/x-pn-realaudio-plugin" to the embed and
that still doesn't help, which means the MIME in the http header is probably
causing the type to be lost? Or, possibly, the type is ignored altogether? Not
sure, so I'll have to see how we handle the MIME processing of that src.

Comment 12

[Marc Attinasi]

Another hint: my Viewer build from today displays this URL just fine, but my
Mozilla from the same build does not. Also, the TYPE attribute seems to matter
in Viewer but not in Mozilla. What does it all mean? I'm still thinking it is
something to do with MIME types... CC'ing mscott in case this rings a bell with him.

Also, updating summary since this has nothing to do with scripting.

Comment 13

[ekrock's old account (dead)]

In the testcase, one example is labeled as "good SRC=" and one is labeled as
"bad SRC=". What is it about each one that makes it "good" or "bad"? Do you mean
that one is pointing at a real file and one's pointing at a nonexistent file, or
is there a syntax error present in the "bad" one that isn't in the "good" one?

Comment 14

[Marc Attinasi]

the Good and BAD designations were pointing out which src= worked and which did
not. However...

Now, in my 10/16 build, they both work, and so does the abcnews page (well,
mostly. The Video plays anyway, but the controls don't show up).
Could somebody verify that the abcnews URL shows the vide for them on a recent
build? I'll now look into why the controls are not showing up.

Comment 15

[ekrock's old account (dead)]

In Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001025 Netscape6/6.0,
I'm still seeing the puzzle piece even though I have RealPlayer installed. This
is on Win NT 4.0 SP4.

Comment 16

[Marc Attinasi]

Mozilla / NS6 definitely has some robustness issues, since Nav can display this
reliably every time, but Moz/NS6 is intermittent in its behavior.

To repeat, other content works fine (see the second testcase
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=17385).

Marking rtm- per discussion with Eric K.

Comment 17

[av (gone)]

Setting 0.8 milestone since this bug is in the list of Big 14.

Comment 18

[Chris McAfee]

http://sports.yahoo.com just changed their realplayer delivery,
it used to be a regular plugin, they have recently dressed it
up going with an ? embedded realplayer in a ? JS window.
Now realplayer loads but never starts up, I was using RTM/w2k.
Works fine in 4.5/w2k.

This is real high profile, AND this is the only way
I can listen to sharks games :-)  How do we mark this
important?

Comment 19

[shrirang khanzode]

let's raise the severity to major

Comment 20

[Marc Attinasi]

I won't be able to work on this any time soo, and since it is now viewed as
important, I'm sending it over to peterl to look at - maybe it should be Andrei's?

Comment 21

[Peter Lubczynski]

I think this bug has changed a little since it was opened. Recapping:

1) The media on sports.yahoo.com redirects to NFL.com and then crashes in a 
Flash plugin. I opened bug 63243. Remove NPSWF32.DLL from your Netscape 4.x & 
6.x plugin directories to get that media to work. At least that worked for me.
2) In attached testcase #2, both of the embeds work for me. 
3) In attached testcase #1 and the URL testcase, I think there is a MIME-type 
problem. Adding TYPE="audio/x-pn-realaudio-plugin" DOES make these work for me 
so I'm guessing the server isn't handing back the correct type or we aren't 
doing the right thing with it. I will continue to investigate, but I don't think 
this one is that serious.

Comment 22

[Peter Lubczynski]

Ahh, I think I found the problem. In nsPluginHostImpl::SetUpPluginInstance() we 
are incorrectly determining the extension.

Comment 23

[av (gone)]

I think we got at least one more bug with the same problem. We can determine 
extension from the URL only in its simplest form -- bla/bla/name.ext 
In this case we have +	mQuery	0x0625add0 
"url=swave/abc/g2demand/morris.rm&?url=swave/abc/g2demand/001016findlay.rm&proto
=dual&plugin=1"

Any ideas how to parse this kind of URLs correctly?

Comment 24

[Peter Lubczynski]

I think the incorrect parsing of the extension may just be a red herring. I 
replaced that code with some a little further down that uses nsStdURL to  
correctly parse. However, the URL doesn't contain any extension at all, it's a  
request for the root document "/" and everything that follows is the input:
http://play.rbn.com/?url=swave/abc/g2demand/morris.rm&?url=swave/abc/g2demand/00
1016findlay.rm&proto=dual&plugin=1

So, I took a look at the raw HTTP transaction, and the server is indeed 
returning the correct MIME type. However, we give up too soon and try to 
render the Default Plugin before we get to the part of 
nsPluginHostImpl::InstantiateEmbededPlugin that starts a NewEmbededPluginStream 
to check for the MIME type from the server. I'll try to straighten this out.

Comment 25

[Peter Lubczynski]

Attachment: patch that will force checking of content-type header before trying the Default plugin

Comment 26

[Peter Lubczynski]

My patch basically bails after NewEmbededPluginStream() is called in 
nsPluginHostImpl::InstantiateEmbededPlugin() if we don't have a MIME type. Then, 
in nsPluginStreamListenerPeer::OnStartRequest(), if indeed we did get the MIME 
type in the header, go ahead and try 
nsPluginHostImpl::InstantiateEmbededPlugin() again. On this second try, we'll be 
able to do the Default plugin.

Comment 27

[av (gone)]

Looks fine to me at a first glance. I think the following two lines in the 
original code
    // We may not have a mime type, but that's ok.  Let's try to render
    // the default plugin.  See bug 41197
no loger needed, since with your patch if mimetype == 0 we bail out before we 
reach this point.

Comment 28

[Peter Lubczynski]

Attachment: needed null pointer checks in nsObjectFrame.cpp for previous patch

Comment 29

[av (gone)]

Looks reasonable. a=r=av.

Comment 30

[Peter Lubczynski]

sr=buster

Patch checked in.

Comment 31

[Peter Lubczynski]

Patches also checked into the branch

Comment 32

[shrirang khanzode]

verifed fixed on windows branch and trunk builds (0117). Also verified on mac 
branch and trunk builds (0117).