All users were logged out of Bugzilla on October 13th, 2018

Plugin streams never get initialized (OnProgress is never called)

VERIFIED FIXED in M10

Status

()

P3
critical
VERIFIED FIXED
20 years ago
2 years ago

People

(Reporter: serhunt, Assigned: rpotts)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
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.

Comment 1

20 years ago
Where can I get npavi?
(Reporter)

Comment 2

20 years ago
I'll send it to you.

Updated

20 years ago
Target Milestone: M9

Updated

19 years ago
Assignee: warren → av

Comment 3

19 years ago
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.

Updated

19 years ago
Whiteboard: m9 blocker?

Comment 4

19 years ago
can I get an update on this later today?
(Reporter)

Updated

19 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 5

19 years ago
I'll give an update by the end of the day
(Reporter)

Comment 6

19 years ago
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?

Updated

19 years ago
Assignee: av → rpotts
Status: ASSIGNED → NEW

Comment 7

19 years ago
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.

Updated

19 years ago
Target Milestone: M9 → M10

Comment 8

19 years ago
We're gonna release note this one for M9.  paulmac, ask verah to do in BOLD.
Moving to M10

Comment 9

19 years ago
release note added!

Updated

19 years ago
Blocks: 12833

Updated

19 years ago
No longer blocks: 12833
QA Contact: paulmac
Summary: Plugins do not get streams
Whiteboard: m9 blocker?
(Assignee)

Updated

19 years ago
Summary: Plugin streams never get initialized (OnStatus is never called)
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Summary: Plugin streams never get initialized (OnStatus is never called) → Plugin streams never get initialized (OnProgress is never called)
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

19 years ago
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...
(Reporter)

Comment 11

19 years ago
Rick could you please clarify your last comment? What should be done to fix
this?
(Assignee)

Comment 12

19 years ago
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...

Updated

19 years ago
QA Contact: paulmac

Comment 13

19 years ago
Assigning QA contact.

Updated

19 years ago
QA Contact: paulmac → shrir

Comment 14

19 years ago
shrir is king of plugins

Comment 15

19 years ago
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Updated

19 years ago
QA Contact: shrir → tever

Comment 16

19 years ago
Setting QA contact, tever@netscape.com

Comment 17

19 years ago
verified:
NT 2000070508
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.