Closed Bug 11376 Opened 25 years ago Closed 25 years ago

Plugin streams never get initialized (OnProgress is never called)

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: serhunt, Assigned: rpotts)

Details

Warren, as you suggested I filed a bug and assigned it to you. You will need our
old npavi.dll plugin to use this test case. But any audio plugin will not play
too. This happens after Necko landing so I suspect something changed in
streaming API which needs to be adjusted in plugin code. I will continue to look
at it too these days.

I marked it critical but this could be M9 stopper. Also component probably
should be changed to Plugins.
Where can I get npavi?
I'll send it to you.
Target Milestone: M9
Assignee: warren → av
I spent some time looking into this, and it doesn't look like a necko bug.
nsPluginStreamListenerPeer::Initialize is never getting called, and
consequently mPStreamListener is never getting set. When necko delivers the
plugin data to nsPluginStreamListenerPeer::OnDataAvailable, it just bails at
nsPluginHostImpl.cpp line 1060.

I think av should debug this from here.
Whiteboard: m9 blocker?
can I get an update on this later today?
Status: NEW → ASSIGNED
I'll give an update by the end of the day
There is something called ProxyProgressEvent, and mPStreamListener used to be
set upon this event. Here is stack from the days it worked:

nsPluginStreamListenerPeer::SetUpStreamListener(nsIURI * 0x0245c470) line 1156
nsPluginStreamListenerPeer::OnProgress(nsPluginStreamListenerPeer * const
0x0245da80, nsIURI * 0x0245c470, unsigned int 0, unsigned int 180224) line 1012
+ 12 bytes
nsDocumentBindInfo::OnProgress(nsDocumentBindInfo * const 0x0245d9d0, nsIURI *
0x0245c470, unsigned int 0, unsigned int 180224) line 1692 + 30 bytes
OnProgressProxyEvent::HandleEvent(OnProgressProxyEvent * const 0x02444040) line
537
StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x02444044) line 473 + 12
bytes
PL_HandleEvent(PLEvent * 0x02444044) line 493 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0105f490) line 454 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000b0194, unsigned int 49293, unsigned int 0,
long 17167504) line 912 + 9 bytes

Something changed, and above does not happen any more. Probably event is not
sent. Can somebody explain me what has changed and what should be done?
Assignee: av → rpotts
Status: ASSIGNED → NEW
I see. We're not getting the OnProgress notification. This either falls under
Rick's domain (docloader related), or Gagan's (http protocol not sending it).
Reassigning to Rick.
Target Milestone: M9 → M10
We're gonna release note this one for M9.  paulmac, ask verah to do in BOLD.
Moving to M10
release note added!
Blocks: 12833
No longer blocks: 12833
URL: http://www.student.oulu.fi/%7esairwas...
QA Contact: paulmac
Summary: Plugins do not get streams
Whiteboard: m9 blocker?
Summary: Plugin streams never get initialized (OnStatus is never called)
Status: NEW → ASSIGNED
Summary: Plugin streams never get initialized (OnStatus is never called) → Plugin streams never get initialized (OnProgress is never called)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I've just checked in the fix for this.

It looks like plugins that do not rely on the cache are working again.  However,
plugins that download their data to the cache and then open up the cache file
are *still* broken until a cache is hooked into necko...
Rick could you please clarify your last comment? What should be done to fix
this?
I believe that some plugins used "stream as file" or some such thing.  I think
that this caused the stream to be downloaded into the cache and then opened up
once all the data was there...

Until we have a necko cache, there's not too much we can do to support this
mechanism...
QA Contact: paulmac
Assigning QA contact.
QA Contact: paulmac → shrir
shrir is king of plugins
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
QA Contact: shrir → tever
Setting QA contact, tever@netscape.com
verified:
NT 2000070508
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.