Closed Bug 85539 Opened 23 years ago Closed 23 years ago

realplayer launches seperately and embed player does not appear

Categories

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

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: shrir, Assigned: peterl-bugs)

References

()

Details

(Keywords: topembed, Whiteboard: [bugscape 12223])

Attachments

(1 file)

used to work earlier, seen on 0612 trunk steps: 1. Go to http://jazz.mcom.com/users/shrir/publish/page-gen.html 2. Change any of the values and click on 'generate page'. Result: After clicking on 'generate page' RealPlayer opens up externally and does not show the plugin embed inside browser window as it used to earlier...
Shrirang, can you please double-check the URL? I get an immediate "...cannot be found" when I try to go to it.
Andre, that's an internal link...lemme try and see if I can post the testcase as an attachment. Thx for the pointer!
btw, just tried, this still happens.
Sometimes this happens by design of Realplayer. This may be a dup and Arun may have more details....
This is also bugscape 12223.
Assignee: av → peterl
Whiteboard: [bugscape 12223]
Attached patch patch from bugscape bug 12223 (deleted) — Splinter Review
------- Additional Comment #9 From Peter Lubczynski 2002-02-26 15:45 ------- Created an attachment (id=4523) testcase with rstp url Here's a testcase showing the problem in Mozilla. You don't need any plugins installed to see the problem. The problem is with NS_OpenURI(). Given an URL with a scheme that's not known to the browser will cause nsIOService::GetProtocolHandler to use the "default" handler and then dispatch it to the OS. I'm not sure what the "right" think to do is here. The browser has no idea how to handle streams of type "rstp". Maybe we should just not open the stream. Checking to see what happens if we don't open the stream at all in this case, Real doesn't automatically start playing, but does work correctly after clicking the play button. I think this may be the right solution. Does anyone know if there is an easy way to prevent NS_OpenURI from dispatching to the OS? ------- Additional Comment #10 From Peter Lubczynski 2002-02-26 18:13 ------- Created an attachment (id=4525) possible fix? This is also bugzilla 85539. Here's a possible fix for this problem: See if we get a protocal handler back from the service manager. Only then can we open the initial stream for the plugin so that the external protocal service isn't used. Please review/comment. ------- Additional Comment #11 From Darin Fisher 2002-02-26 18:22 ------- peterl: this begs the question... how do you have an URL to something for which there is no internal protocol handler? was this URL created using the external protocol handler? seems like you might want to move this code to URL creation instead. ------- Additional Comment #12 From Peter Lubczynski 2002-02-26 18:49 ------- The URL comes from layout, such as in the testcase: <embed type="audio/x-pn-realaudio-plugin" SRC="rtsp://live1.stream.aol.com/redundant/*/encoder/aplive.rm?embed" HEIGHT=200 WIDTH=200> I guess I could stop |nsPluginHostImpl::NewEmbededPluginStream| from being called in the first place, as is done with Java, but there are multiple call sites in |InstantiateEmbededPlugin| ------- Additional Comment #13 From Darin Fisher 2002-02-26 19:10 ------- is that where the nsIURI is instantiated? hmm.. that would make sense. then i guess your patch is as good as it's gonna get ;-) ------- Additional Comment #14 From Nicholas B 2002-02-26 19:22 ------- If the potential patch for this bug can be R and SRd, we need to pick this up in the next Mozilla pull. The last Mozilla pull was scheduled to occur 2/27/2002, but could occur on 2/28/2002. Please contact me if you have any questions, comments or concerns. Thanks, Nicholas ------- Additional Comment #15 From Darin Fisher 2002-02-26 19:39 ------- (From update of attachment 4525 [details] [diff] [review]) one comment on this patch: if you already have the nsIProtocolHandler you want to use, then calling NS_OpenURI is overkill. it would be better to call NewChannel on the nsIPRotocolHandler. ------- Additional Comment #16 From Peter Lubczynski 2002-02-27 08:55 ------- Created an attachment (id=4531) slightly better patch I think patch is slightly better because it does similar what we do for Java in |InstantiateEmbededPlugin|. It saves some extra work and allocation of a |nsPluginStreamListenerPeer| in |NewEmbededPluginStream|. Please review. ------- Additional Comment #17 From Darin Fisher 2002-02-27 09:36 ------- patch looks clean to me r/sr=darin.
Comment on attachment 71695 [details] [diff] [review] patch from bugscape bug 12223 sr=darin
Attachment #71695 - Flags: superreview+
Keywords: topembed
Status: NEW → ASSIGNED
Keywords: patch, review
Priority: -- → P1
Target Milestone: --- → mozilla0.9.9
Keywords: edt0.9.4
Comment on attachment 71695 [details] [diff] [review] patch from bugscape bug 12223 looks good, r=av
Attachment #71695 - Flags: review+
Chofmann, can I get drivers approval for the trunk?
Keywords: reviewapproval
requesting edt0.9.4+
Attachment #71695 - Flags: approval+
a=chofmann for 0.9.9 and for the 0.9.4 branch
patch in trunk and 0.9.4 branch, marking FIXED
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Keywords: approvalfixed0.9.4
Resolution: --- → FIXED
Keywords: edt0.9.4edt0.9.4+
v
Status: RESOLVED → VERIFIED
Depends on: 866936
No longer depends on: 866936
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: