Closed Bug 35324 Opened 24 years ago Closed 23 years ago

Browser doesn't load plug-in correctly - StreamAsFile not implemented correctly

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: alec, Assigned: serhunt)

References

(
URL
)

Details

Attachments

(1 file)

registry.dat that screws up StreamAsFile for some reason
918 bytes, application/octet-stream
Details 
I think something broke in the backwards compatible support for the old plug-in 
API in Mozilla.  We've been running this plug-in in NN4.x and IE4,5 for 
months/years.  I now ran this plug-in in Mozilla M14 and NN6 PR1 and in both 
the plug-in doesn't correctly and the browser GPFs when I close it.  I put the 
two files with plug-in specific code in them as links on the site.

Let me know if you need me to try anything.

Thanks
Yes, I downloaded the Interact v4.4 and when I load the page, see only the 
"Interact Math Plugin" text in the center and nothing happens.
OS: other → Windows NT
Hardware: Other → PC
shrir@netscape.com figured it out, but I neglected to mention you can download 
the plug-in by going to http://awl.intellipro.com and clicking on download plug-
in or direct from this link: http://www.mathxl.com/download/setup44.exe

The installer will install a DLL on your machine in the plugins directory where 
netscape is installed.  I copied the DLL to a plugins dir Mozilla\bin to test.
Am still seeing this problem(2000042709)
Confirming.

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Target Milestone: --- → M18
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: M18 → Future
Keywords: 4xp
I hear rumors that Netscape is making a decision about releasing Netscape 6.  I 
would appreciate this bug being looked at before then.  This plug-in forms the 
core of our site and we would simply turn everyone away from our site using 
Netscape 6 if it doesn't work.

Excuse the rant, but I also see PLENTY of display anomalies with tables and CSS 
still unfixed...  I really hope Netscape keeps whatever's left of its 
credibility in mind before releasing something less mature than IE4 was 2 years 
ago...
Reporter: is this still happening with a lastest nightly? Could you be more 
specific as to which parts of the API are not working correctly. Thanks!
I can confirm that this is still happening with today's build and the interact 
math plugin. I still see what I have mentioned in my comment earlier..
could this be in anyway related to bug 58491 ?
Reporter do you still see this bug in the latest builds?
Bug still happens in 9-28-01 nightly build.  I tracked it down.  StreamAsFile 
is not implemented correctly.  In Netscape 4.x when I return "NP_ASFILE", 
StreamAsFile is called with the filename I want.  In Mozilla, "WriteReady" 
and "Write" are called (when they shouldn't be!) and StreamAsFile is called 
with a blank filename.

Not related to bug #58491.
URL: http://awl.intellipro.com/plugtest.htm → http://demomml.intellipro.com/ipttest...
Summary: Browser doesn't load plug-in correctly → Browser doesn't load plug-in correctly - StreamAsFile not implemented correctly
is anyone working on this bug ? Can it be retriaged ? Thx!
Alec, could you further explain the problem.

According to the 4.x API spec, when NP_ASFILE is returned, WriteReady/Write
should be called before StreamAsFile. See:
http://developer.netscape.com/docs/manuals/communicator/plugin/pgfn2.htm#1007302

    * NP_NORMAL (Default): Delivers stream data to the instance in a series of
calls to NPP_WriteReady and NPP_Write. The plug-in can process the data
progressively as it arrives from the network or file system.

    * NP_ASFILEONLY: New in Netscape Navigator 3.0. Communicator saves stream
data to a file in the local cache. When the stream is complete, Communicator
calls NPP_StreamAsFile to deliver the path of the file to the plug-in. If the
stream comes from a local file, the NPP_Write and NPP_WriteReady functions are
not called. NPP_StreamAsFile is simply called immediately. This mode allows the
plug-in full random access to the data using platform-specific file operations.

    * NP_ASFILE: File download. Differs from NP_ASFILEONLY in that data is
delivered to the plug-in, through a series of calls to NPP_Write and NPP_Write,
as it is saved to the file (as in mode NP_NORMAL). When the stream is complete,
Communicator calls NPP_StreamAsFile to deliver the path of the file to the
plug-in. If the data in the stream comes from a file that is already local, the
data is read, sent to the plug-in through NPP_Write, and written to a file in
the local cache.

NOTE: Most plug-ins that need the stream saved to a file should use the more
efficient mode NP_ASFILEONLY (above); this mode is preserved for compatibility
only. §

Peter, you are right about the spec.  Netscape 4.7x and all versions of IE 
don't behave that way though.  They seem to treat NP_ASFILE exactly like 
NP_ASFILEONLY.  I don't mind if Mozilla follows the spec more strictly and I 
have to change to returning NP_ASFILEONLY, but I have tried this and 
NP_ASFILEONLY mode also calls "Write" and "WriteReady".  

In addition, it was my reading of the spec that after the calls to "Write" 
and "WriteReady" in NP_ASFILE mode, StreamAsFile would be called with the 
filename from the cache directory.  So, if a plug-in wants to truly stream, 
they can get the data as it comes in the write calls, or they may ignore those 
calls and simply wait for the file to be done and read the file passed in 
StreamAsFile.

In all cases, StreamAsFile is called by Mozilla with a blank filename...
Strange! I just checked in the debugger and with plugin logging and I saw the
correct behavior. In fact, the plugin came up with a message box with the
filename in it! Is your disk cache turned off?

If you have a debug build, you can use plugin logging which should show all the
4.x API calls. Set this environment variable:

NSPR_LOG_MODULES=PluginNPP:8
OK, I have been installing new builds on the same machine for months now and 
apparently the disk cache had been turned off at one point (I certainly never 
turned it off).  What's funny is that I turned it on and it still didn't work 
(this time it didn't even call write or writeready).  So I installed on a 
different machine and it called stream as file properly.  I went back to my 
main machine and renamed the "registry.dat" file so it would recreate my 
profile and when making a new profile it fixed itself up.  So, I guess there 
was a bug somewhere along the line using "registry.dat" from old installs.  
It's probably not important at this point, but I've attached my old broken 
registry.dat for curiosity's sake if you'd like to have a look at it.

My plug-in still doesn't load, but it's getting the filename properly.  I'm 
going to look into what the roadblock is now and write back.

Thanks.
FIXED!

This plug-in had at its core a windows app that took a filename as an argument 
and used the file extension to determine what to do.  That legacy portion 
remained and worked fine due to all other browsers keeping the file extension 
on the cache file.  Mozilla wasn't keeping the file extension so my plug-in was 
sitting there not knowing what to do.  I'll fix it up so it looks at the MIME 
type (I hardcoded a quick test and the rest of the plug-in came up fine).

BTW, any special reason for not adding the file extension?  Maybe some other 
plug-ins made this assumption?

Anyway, it's great that it's working now.  Thanks!
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I think we have a bug on this against netlib.
err fixed? Or do you mean invalid?
Well StreamAsFile was most definitely broken at the time I started testing it 
over a year ago.  It was fixed in the meantime, but I have no idea exactly when 
due to the registry.dat screwing up future tests so I think it should stay 
as "FIXED".
v
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: