realplayer launches seperately and embed player does not appear

VERIFIED FIXED in mozilla0.9.9



18 years ago
6 years ago


(Reporter: shrir, Assigned: peterl-bugs)



Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [bugscape 12223], URL)


(1 attachment)



18 years ago
used to work earlier, seen on 0612 trunk

1. Go to
2. Change any of the values and click on 'generate page'.
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

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

Comment 2

17 years ago
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

17 years ago
btw, just tried, this still happens.

Comment 4

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

Comment 5

17 years ago
This is also bugscape 12223.
Assignee: av → peterl
Whiteboard: [bugscape 12223]

Comment 6

17 years ago
Created attachment 71695 [details] [diff] [review]
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

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

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

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

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

Attachment #71695 - Flags: superreview+


17 years ago
Keywords: topembed


17 years ago
Keywords: patch, review
Priority: -- → P1
Target Milestone: --- → mozilla0.9.9


17 years ago
Keywords: edt0.9.4

Comment 8

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

looks good, r=av
Attachment #71695 - Flags: review+

Comment 9

17 years ago
Chofmann, can I get drivers approval for the trunk?
Keywords: review → approval

Comment 10

17 years ago
requesting edt0.9.4+


17 years ago
Attachment #71695 - Flags: approval+

Comment 11

17 years ago
a=chofmann for 0.9.9 and for the 0.9.4 branch

Comment 12

17 years ago
patch in trunk and 0.9.4 branch, marking FIXED
Last Resolved: 17 years ago
Keywords: approval → fixed0.9.4
Resolution: --- → FIXED


17 years ago
Keywords: edt0.9.4 → edt0.9.4+

Comment 13

17 years ago


6 years ago
Depends on: 866936


6 years ago
No longer depends on: 866936
You need to log in before you can comment on or make changes to this bug.