Closed Bug 157792 Opened 22 years ago Closed 22 years ago

WMP regression, bad NPP_StreamAsFile

Categories

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

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.2alpha

People

(Reporter: Aric, Assigned: srgchrpv)

References

()

Details

(Whiteboard: [PL2:NA])

Attachments

(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
BuildID:    2002052918

The symptom is that WMP has stopped working for Crossover Plugin with
Mozilla 1.0. Embedded players are failing and either crashing mozilla or
bouncing back from the page with the browser. I have done some
investigating from our end using the url

Using Crossover Plugin to get Windows Media Player 6.4

http://spaceflight.nasa.gov/realdata/index.html
click on the NetShow link under Nasa TV.

This is also reproducable with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610

the problem appears to be that Mozilla calling NPP_StreamAsFile when the stream
is not requests as a file.

Here are the specifics from a logfile generated by Crossover Plugin:
| 3303|npwine|nppclient.c /1084| Call NPP_NewStream
| 3303|npwine|nppclient.c /1085| [type video/x-ms-asf|url
http://spaceflight.nasa.gov/realdata/nasatv/HighSpeed.asx|end 98]
| 3303|npwine|nppclient.c /1086| [notifyData 0x0|seekable 1|stype 1]
.
.
.
| 3303|npwine|nppclient.c /1147| Exit NPP_NewStream [stype 1]
| 3303|npwine|nppclient.c /1151| Ret NPP_NewStream: NPError 0|
[NPERR_NO_ERROR]

this shows that the stream is being created and returns an stype of 1,which is
NP_NORMAL

Then as expected an NPP_WriteReady is called followed by an NPP_Write however
when the NPP_Write returns we see this

| 3303|npwine|nppclient.c /1415| Ret NPP_Write = 98
| 3303|npwine|nppclient.c /1279| Call NPP_StreamAsFile
fname=/home/aric/.mozilla/aric/2fb3q5dt.slt/Cache/9B6AF17Fd01

WMP gets the StreamAsFile and then calls

| 3316|server|npnclient.c / 143| Call NPN_GetURL [URL
javascript:history.back();|target (null)]


When I look at the identical setup with Netscape 4.78 it is the same until the
return of the NPP_Write.

| 3451|npwine|nppclient.c /1415| Ret NPP_Write = 98
| 3451|npwine|nppclient.c /1437| Call NPP_WriteReady
.
.
.
| 3451|npwine|nppclient.c /1479| Ret NPP_WriteReady = 2147483647
| 3451|npwine|nppclient.c / 739| Call NPP_DestroyStream

and things work with Netscape 4.78

If there is anything I can do to help with tracking down this problem
please tell me.



Reproducible: Always
Steps to Reproduce:
1.With Crossover Plugin and WMP installed go to the url
2.Click on NetShow
3.

Actual Results:  WMP briefly loads up then the web page bounces back to the
original page

Expected Results:  NasaTV should play in an embedded WMP plugin window
handing this over to serge
Assignee: beppe → serge
Priority: -- → P3
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.0.2
hmm, it looks like we are incorrectly calling NPP_StreamAsFile() for NP_NORMAL
stream type, according to
http://developer.netscape.com/docs/manuals/communicator/plugin/pgfn2.htm#1007302
we have to call it only for NP_ASFILE* type.
I doubt this is the regression, that call has been in the code for a long time
I've just check rev=1.200
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp&rev=1.200&root=/cvsroot#1379
which was created on 13 Feb 2001 13:46 the call is in there.
ccing plugins developers
av, peterl any idea why we're calling NPP_StreamAsFile() for NP_NORMAL stype?
Attached patch patch v1Splinter Review
Serge, but looks like we still set a local cache file in any case. If we are not
going to use it for mStreamType >= nsPluginStreamType_AsFile, would not it make
sense not to set it for this case?
Please disregard my last comment, I missed other situations when we still need
the local file.
Target Milestone: mozilla1.0.2 → mozilla1.2alpha
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp, patch
the fix for this bug has been checked in by patch for bug 145054
http://bugzilla.mozilla.org/attachment.cgi?id=96929&action=view
I'm marking this as fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
fixd.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: