Closed
Bug 54437
Opened 24 years ago
Closed 24 years ago
realplayer does not load as embedded plugin in some cases (MIME problems?)
Categories
(Core Graveyard :: Plug-ins, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.8
People
(Reporter: shrir, Assigned: peterlubczynski-bugs)
References
()
Details
(Keywords: top100, Whiteboard: [rtm-])
Attachments
(4 files)
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•24 years ago
|
||
cc :ekrock. This bug was found using testcase suite from real.
Comment 2•24 years ago
|
||
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.
Priority: P3 → P1
Comment 3•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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
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•24 years ago
|
||
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.
Assignee: av → attinasi
Keywords: qawanted
Summary: realplayer does not load as a plugin in window → realplayer does not load as a plugin in frameset window with contents dynamically written by JavaScript
Whiteboard: [rtm need info]
Comment 8•24 years ago
|
||
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.
Status: NEW → ASSIGNED
Comment 9•24 years ago
|
||
Comment 10•24 years ago
|
||
Comment 11•24 years ago
|
||
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•24 years ago
|
||
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.
Summary: realplayer does not load as a plugin in frameset window with contents dynamically written by JavaScript → realplayer does not load as embedded plugin in some cases (MIME problems?)
Comment 13•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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.
Whiteboard: [rtm need info] → [rtm-]
Target Milestone: --- → Future
Comment 17•24 years ago
|
||
Setting 0.8 milestone since this bug is in the list of Big 14.
Target Milestone: Future → mozilla0.8
Comment 18•24 years ago
|
||
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 20•24 years ago
|
||
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?
Assignee: attinasi → peterlubczynski
Status: ASSIGNED → NEW
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 21•24 years ago
|
||
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.
Assignee | ||
Comment 22•24 years ago
|
||
Ahh, I think I found the problem. In nsPluginHostImpl::SetUpPluginInstance() we
are incorrectly determining the extension.
Comment 23•24 years ago
|
||
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?
Assignee | ||
Comment 24•24 years ago
|
||
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.
Assignee | ||
Comment 25•24 years ago
|
||
Assignee | ||
Comment 26•24 years ago
|
||
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•24 years ago
|
||
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.
Assignee | ||
Comment 28•24 years ago
|
||
Comment 29•24 years ago
|
||
Looks reasonable. a=r=av.
Assignee | ||
Comment 30•24 years ago
|
||
sr=buster
Patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 31•24 years ago
|
||
Patches also checked into the branch
Reporter | ||
Comment 32•24 years ago
|
||
verifed fixed on windows branch and trunk builds (0117). Also verified on mac
branch and trunk builds (0117).
Status: RESOLVED → VERIFIED
Updated•23 years ago
|
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•