85539 - realplayer launches seperately and embed player does not appear

Status: VERIFIED FIXED

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

Description

[shrirang khanzode]

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...

Comment 1

[André Dahlqvist]

Shrirang, can you please double-check the URL? I get an immediate "...cannot be
found" when I try to go to it.

Comment 2

[shrirang khanzode]

Andre, that's an internal link...lemme try and see if I can post the testcase as 
an attachment. Thx for the pointer!

Comment 3

[shrirang khanzode]

btw, just tried, this still happens.

Comment 4

[Peter Lubczynski]

Sometimes this happens by design of Realplayer. This may be a dup and Arun may
have more details....

Comment 5

[Peter Lubczynski]

This is also bugscape 12223.

Comment 6

[Peter Lubczynski]

Attachment: patch from bugscape bug 12223

------- 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 7

[Darin Fisher]

Comment on attachment 71695 [details] [diff] [review]
patch from bugscape bug 12223

sr=darin

Comment 8

[av (gone)]

Comment on attachment 71695 [details] [diff] [review]
patch from bugscape bug 12223

looks good, r=av

Comment 9

[Peter Lubczynski]

Chofmann, can I get drivers approval for the trunk?

Comment 10

[Nicholas B]

requesting edt0.9.4+

Comment 11

[chris hofmann]

a=chofmann for 0.9.9 and for the 0.9.4 branch

Comment 12

[Peter Lubczynski]

patch in trunk and 0.9.4 branch, marking FIXED

Comment 13

[shrirang khanzode]

v