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)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.9
People
(Reporter: shrir, Assigned: peterl-bugs)
References
()
Details
(Keywords: topembed, Whiteboard: [bugscape 12223])
Attachments
(1 file)
(deleted),
patch
|
serhunt
:
review+
darin.moz
:
superreview+
chofmann
:
approval+
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
Shrirang, can you please double-check the URL? I get an immediate "...cannot be
found" when I try to go to it.
Reporter | ||
Comment 2•23 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!
Reporter | ||
Comment 3•23 years ago
|
||
btw, just tried, this still happens.
Comment 4•23 years ago
|
||
Sometimes this happens by design of Realplayer. This may be a dup and Arun may
have more details....
Comment 5•23 years ago
|
||
This is also bugscape 12223.
Assignee: av → peterl
Whiteboard: [bugscape 12223]
Comment 6•23 years ago
|
||
------- 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•23 years ago
|
||
Attachment #71695 -
Flags: superreview+
Updated•23 years ago
|
Comment on attachment 71695 [details] [diff] [review]
patch from bugscape bug 12223
looks good, r=av
Attachment #71695 -
Flags: review+
Comment 9•23 years ago
|
||
Chofmann, can I get drivers approval for the trunk?
Comment 10•23 years ago
|
||
requesting edt0.9.4+
Updated•23 years ago
|
Attachment #71695 -
Flags: approval+
Comment 11•23 years ago
|
||
a=chofmann for 0.9.9 and for the 0.9.4 branch
Comment 12•23 years ago
|
||
patch in trunk and 0.9.4 branch, marking FIXED
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Keywords: approval → fixed0.9.4
Resolution: --- → FIXED
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
•