crash on visiting page with Shockwave content after SW registration

VERIFIED FIXED in mozilla0.9.2



19 years ago
18 years ago


(Reporter: kcunningham, Assigned: serhunt)


({crash, shockwave})

crash, shockwave
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: rtm stopper, URL)


(6 attachments)



19 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) Gecko/20001019 Netscape6/6.0
BuildID:    2000092908

 When you use the shim installer on winows toward the end of the shockwave
install process N6pr3 crashes at the "Welcome" page

Reproducible: Always
Steps to Reproduce:
1. Install a full pinging version of Shockwave 8 (you can get by going to or have to launch browser and go to a
shockwave game to continue install process)
2. Complete registration.
Results: The welcome movie page at will attempt
to refresh multiple times before Netscape crashes.
Expected: Not to do that.

Actual Results:                              crash

Expected Results:                              no crash

       John Pfeiffer's bug 63050 in our bugbase


19 years ago
Keywords: rtm, shockwave

Comment 1

19 years ago
Is it Mac only? If so, please update OS appropriately.


19 years ago
Assignee: av → peterl
OS: Windows 98 → Mac System 9.x
QA Contact: shrir → peterl

Comment 2

19 years ago
OS:Mac ,reassign:peterl

Comment 3

19 years ago
No, this is not a Mac bug. We've seen this bug on all flavors of Windows only. 
It only occurs after the registration process. Since the registration process on 
the Mac is broken (see bug 57012), the Mac can not be tested for this bug.   
Here's a tip on how to force your current installation of Shockwave to go thru 
the registration process. 

1. Make sure the following registry entries have these values:
HKCU/Software/Macromedia/Shockwave 8/InstallState = fullinstall
HKCU/Software/Macromedia/Shockwave 8/AutoUpdate = y
HKCU/Software/Macromedia/Shockwave 8/CollectStatistics = y

2. Delete the following registry entries:
HKCU/Software/Macromedia/Shockwave 8/nextpingdate
HKCU/Software/Macromedia/Shockwave 8/sw702down
HKCU/Software/Macromedia/Shockwave 8/sw702installed

3. View any Shockwave content.
Marking crash.
Keywords: crash

Comment 5

19 years ago
seems like this is a critical bug to fix for rtm
Severity: normal → critical
Ever confirmed: true
OS: Mac System 9.x → All
Priority: P3 → P1
Hardware: PC → All

Comment 7

19 years ago
this might be a frameset problem.  here's the source of the problem page.  What
seems to happen is the frame with the ad gets repeated until you click the stop
button, then you crash going to another page (I hit the Back button.)

<html> <head> <title>Macromedia Web Player Download Center</title> </head>
<frameset rows="1*,64" cols="*" border="0" framespacing="0" frameborder="NO"
marginwidth="0" marginheight="0"> <frame
src="/shockwave/download/download.cgi?application/x-director" frameborder="NO"
marginwidth="0" marginheight="0" noresize name="contents"> <frameset
cols="292,1*" border="0" framespacing="0" frameborder="NO" marginwidth="0"
marginheight="0"> <frame src="/nav/find.fhtml" frameborder="NO" marginwidth="0"
marginheight="0" noresize scrolling="NO" name="find"> <frame
src="/shockwave/ad.fhtml" frameborder="NO" marginwidth="0" marginheight="0"
noresize scrolling="NO" name="ad"> </frameset> </frameset> <noframes> <body
bgcolor="#FFFFFF"> Your web browser does not support frames.
Please upgrade to the latest
<a href="/OUTGOING/">Netscape</a> or <a
href="/OUTGOING/">Internet Explorer</a>
</body> </noframes> </html>

Comment 8

19 years ago

Comment 9

19 years ago
So that we don't get confused, this bug is not about the bad markup on that 
link. That sure is a problem, but it has to do with Macromedia's CGI rather than  
Mozilla. That URL doesn't work in any browser. Remove everything after the 
question mark, it it works properly. I have already e-mailed Kelly at Macromedia 
to let her know.

If you go to the correct URL and download shockwave, you'll see this crash. I'm 
trying to get a usable stack right now, but I think it could be crashing inside 
the actual plugin.

Comment 10

19 years ago
right, there are 2 separate bugs here.  I'll submit the crasher bug on the
shockwave frameset page separately

Comment 11

19 years ago
pollmann:  can you confirm whether this is a frameset bug, or bad source from

krock:  there's a pretty good chance this is just irrational source from
macromedia.  We may need to fix this on their side.

Comment 12

19 years ago
Okay, I got a consistant stack, but it's very messy. I could use some help on 
this one.

Comment 14

19 years ago
Okay, I've narrowed down the problem.

First, to reproduce:
1) Delete the Entire Shockwave 8 key in the HKCU/Software/Macromedia in the 
2) Go to any page with Shockwave content.
3) Finish the registration and notice the crash.

We are crashing because the registration process is redirecting to the following 
URL: javascript:window.history.go(0)

This needs to be stopped. Any ideas?

Comment 15

19 years ago
Just a note: This crash isn't that bad because it only happens the FIRST time 
you go to a shockwave page and register. After the crash, restarting the browser 
and going back to that page will not crash again.

Comment 16

19 years ago
jst, radha, mscott:  see Peter's comment on 2000-11-01 17:26
is there any known problem with a page loading URL: javascript:window.history.go(0)?
any hints you can give us for figuring out why this crashes?

Comment 17

19 years ago
I no longer think the javascript:history.go(0) is causing the problem, at least 
not directly. It appears that there is another javascript command being 
sent by the registration process afterwards, and this one is clearly incorrect, 
with invlaid chacaters. If I go this far, I don't even get a stack trace. I may 
need Macromedia's help on this one.

Comment 18

19 years ago
Looking at this again, the Shockwave 8.5 installer doesn't seem to crash because
it skips the registration step. Looking at the Talkback stack, it looks like the
crash is in IML32.DLL which is a Macromedia DLL.

Comment 19

19 years ago
Sure looks like it's time to get this off the rtm radar.  The problems appear to
be exposed by Macromedia's site and/or dll and would not be a topcrash.  Anyone
involved willing to admit this is rtm-?
Whiteboard: [need minus]

Comment 20

19 years ago
Adding [rtm-]
Whiteboard: [need minus] → [rtm-]

Comment 21

19 years ago
Ok, this bug has changed a little since last visited. It appears that it is not 
the registration process that causes the crash, but visiting any page that has 
SW content after completing registration. Visiting Flash content after 
registration does not cause a crash. 

Steps to reproduce:
1) Delete the Shockwave 8 registry key (HKCU/Software/Macromedia)
2) Go to URL above that has a Shockwave movie
3) Fill in registration info
4) You get redirected to the "Thanks for registering" page
5) Do not click on any link on this page, go to any other plain page like Yahoo. 
6) Revist the URL above (or any other shockwave content) and you crash. 

I can not reproduce this in the debugger because during registration, after 
clicking on the first "Next" button, the whole thing hangs (bug doesn't crash). 
That sounds like bug 57012 but it's weird that it only happens in the debugger.

Talking with Peter Grandmaison from Macromedia about possible ideas. 
Keywords: rtm
Summary: crash at sw welcome center page after registration. → crash on visiting page with Shockwave content after SW registration
Whiteboard: [rtm-]

Comment 22

19 years ago
Comments in an e-mail from Peter Grandmaison:

Netscape 6 never invokes np_shutdown ... Other browsers unload our plugin when 
the last shockwave instance is deleted, but Netscape 6 keeps it
loaded until the application terminates ... at which point it should still call 
shutdown, but doesn't. Although I have no real data yet, this difference may be
what's causing the crash on install (or after registration). That is, it is a 
bug on mozilla's part to not call shutdown, however, the difference in when you
unload the plugin may be revealing bugs in shockwave when installing.

I think this may have to do with bug 45009

Comment 23

19 years ago
Setting milestone to Mozilla 0.8.
Target Milestone: --- → mozilla0.8

Comment 24

19 years ago
Changing peterl-retired to peterlubczynski
Assignee: peterl-retired → peterlubczynski

Comment 25

19 years ago
By fiddleing around with the active plugin instances in the debugger, I was able 
to confirm that we in fact are NOT calling NPP_Shutdown() when the last instance 
of a plugin is stopped. The 4.x plugin API clearly states that NPP_Shutdown() 
should be called when the last instance of the plugin is destoryed.

Adding a call to NPP_Shutdown() at the right time isn't too much of a problem, 
however, calling NPP_Initilize when revisiting the plugin may be a little of a 
challenge as there are some data structures that need to be destroyed and 

Comment 26

18 years ago
The new plugin API states that the plugin remains in memory so Shutdown probably 
shouldn't be called for those plugins.
Nom. nsbeta1. Shockwave backward compatibility bug, and high-quality plug-in
support is a priority for embedded applications.
Keywords: nsbeta1
Wait a minute Eric.  Does Peter's last comment say that according to the API,
the plug-in should not be making the call that it is, and that is what is
causing it to crash?  Or am I missing something?

Comment 29

18 years ago
There are a few things here:

1) With 4x plugins, NPP_Shutdown should be called when the last instance is 
destroyed but currently isn't
2) However, XPCOM plugins should not do this
3) This bug has morphed yet again. Instead of crashing now, you are thrown into 
a loop where you continually reload a page. 

Looks like Macromedia changed the content seen after registration which effects 
this bug. I need to contact them again to re-evaluate the problem.


18 years ago
Target Milestone: mozilla0.8 → mozilla0.9
Working on the theory that this is related to plugin lifetime and teardown 
issues, there are a number of active bugs which either touch on or reference 
this. These include 45009 (already noted), 41880, 49510, 62788, and 65661.

It is possible that there may be multiple issues to deal with here as well.
 - the legacy support needs to do the right thing, i.e. shutdown properly.
 - the XPCOM support needs to do what the documentation says it does.
 - plugin vendors need to understand that the functionality is different
   between the two implementations.

If having multiple teardown implementations in a single (Legacy & XPCOM combo) 
plugin is going to be difficult to overcome, we may need to rethink the 
implementation. Not, mind you, that I'm suggesting this is a good idea at this 
late state... 

Adding nhart to cc list because I know he has some experience here...

Comment 31

18 years ago
I just verified this on the trunk(0126) on mac and I see no crash after the 
registration is completed. The welcome movie page still tries to refresh itself 
and does not load. However, the test url works fine and there is no crash.

Comment 32

18 years ago
Really? Good news. So this may be actually fixed indirectly by another check-in?

Shrirang, can you try visiting another page with Shockwave content after 
registration. I remember this bug regressed so that it took a little more effort 
 to crash, but I still crashed if I visited other pages with shockwave right 
after registration.

I will also double-check.
QA Contact: peterl-retired → shrir

Comment 33

18 years ago
oh well, still crashes on windows trunk immediately after the update dialog is 
done with. But on mac trunk, as i said before, it does not crash and I have to 
restart the browser to see shockwave working. 

Comment 34

18 years ago
Peter Grandmason, 
can you take another look in your debugger to see why shockwave performs so
weird after registration. Recent builds have many improvments. I tried calling 
NPP_Shutdown after the last instance was destroyed, but that didn't seem solve
this problem. 

Comment 35

18 years ago
The SetWindow() patch in bug 68759 delays the crash untill PluginSaftey can 
catch it and prevent it.

However, Shockwave doesn't work on any page until you either do reload by:
javascript:navigator.plugins.refresh(true); or restart the browser.

Small step, but in the right direction.


18 years ago
Depends on: 45009

Comment 36

18 years ago

Comment 37

18 years ago
Please review the patch and give it a try.

What it does. When we leave the page we should _not_ keep the plugin instance if 
this is an old style plugin. Looks like we need to sacrifice this feature. It 
was not supposed to be for 4x plugins anyway. So in StopPluginInstance we now 
check it for being old style, remove association from the active instance list, 
unload the dll and clear nsPluginTag.mEntryPoint and nsPluginTag.mLibrary. The 
last two actions are necessary because these members need to be null when we 
meet this mime type again in order to load the plugin from the very ground.

Comment 38

18 years ago
This is great! Wonderful Andrei!

I'm still having some problems on Windows with the patch (will test on Mac). It 
seem to be stuck in a forever loop with when it finishes with registration. 
However, it does not crash when visiting another page. Do you see this behavior 
too? I am using a the fresh tip of nglsrc and nsObjectFrame.

Comment 39

18 years ago
I saw this before I applied the patch, but it works for me as a champ with it.

Comment 40

18 years ago
Trying this again on Windows, I it worked one out of 2 times I tried. The other 
time, it crashed. I will try to narrow down the remaining crash.

Comment 41

18 years ago
Would you give me the exact steps to reproduce the crash? Including urls.

Comment 44

18 years ago
I've been using:

as my test page. Sometimes I get a crash in 
ns4xPluginStreamListener::OnStartBinding. Looks like mStarted is false. Attached 
a patch to check for it as we probably should anyway.

In other times, I get the dialog attached. 

My gut says this is a race condition of some sort, as I'm going through 
registration too quickly and the streams don't finish. I will further test this 
tonight on my home machine.

Comment 45

18 years ago
I saw the script error message occasionaly both before and after my patch has 
been applied. Probably a different problem. But I never crashed in StartBinding. 
This check on mStarted is probably good thing to do in all places like the check 
for pdata we recently added.

Comment 46

18 years ago
Ok, that makes more sense to me. That dialog must be another error. As long as 
the mStarted check is in (and I also agree it should be before all NPP calls), 
then the patch gets a r= from me.

In ANY case, I CAN NOT crash after registration. A simple reload gets it 
working if something gets hicked up.

Reassigning to you.
Assignee: peterlubczynski → av

Comment 47

18 years ago
peterl gave his r= in private e-mail.

Comment 48

18 years ago
looks good, sr=waterson

Comment 49

18 years ago
Checked in --> fixed
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 50

18 years ago
verified this on windows 0419 build. I used the shockwave 3d installer. Part of 
the installation was completed. Then I launched 6.x and went to a shockwave 
movie. An update window came up and the rest of the installation completed. I 
j had to hit reload to see the movie working..
 Then I went to this welcome page and it loaded fine. There was no crash. Since 
we are tracking the installation problem on mac in bug 35916, am marking this 
VERIFIED since this is fixed on windows.

Comment 51

18 years ago
is the issue here is how NS is handling the cache dump? Nevertheless, 
This is still occurring. the activity bar states : read 
Javascript'window.location +"_swmenu_unique_". The sw loading bar 
appears but then does not create any progress.  Any reloading or going 
back a page causes NS to crash with the following reported:
NETSCP6 caused an invalid page fault in
module PLUGIN.DLL at 0167:01c08e83.
EAX=00000102 CS=0167 EIP=01c08e83 EFLGS=00050293
EBX=00000000 SS=016f ESP=057aff88 EBP=057aff98
ECX=dcb34180 DS=016f ESI=bff92d08 FS=51d7
EDX=00017b04 ES=016f EDI=00000014 GS=0000
Bytes at CS:EIP:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Stack dump:
819759e4 819a9b0c 00000008 0000000a 057affcc bff88f20 00000000 
819a9b0c 00000008 819759e4 00000007 057affa4 057afdb8 ffffffff 
bffc05b4 bff79050 
Resolution: FIXED → ---

Comment 52

18 years ago
I had mentioned this problem in bug 57012 and in bug 35916 here: 
- Additional Comments From shrirang khanzode 2001-04-24 15:41 -------

Comment 53

18 years ago
resetting milestone from m.9 to ---.  If this is an m.9.1 stopper, please get it
on the list and approved.
Target Milestone: mozilla0.9 → ---

Comment 54

18 years ago
this has resurfaced and really should be an m0.9.1 stopper.
Keywords: mozilla0.9.1


18 years ago
Blocks: 35916

Comment 55

18 years ago
note that there are test cases resident on various machines, but the chief test
is to see whether or not it crashes on the Welcome page:
Unfortunately, yes :-(

Comment 56

18 years ago
Well, looks like this has regressed since AV fixed it last....shoot!

Okay...all mine....setting milestone for mozilla0.9.2. IMO, I think this is a 
mozilla0.9.1 stopper but I think I may have missed that boat....:-( Please 
change if I am wrong.
Assignee: av → peterlubczynski
Target Milestone: --- → mozilla0.9.2

Comment 57

18 years ago
Over to AV...welcome back :)
Assignee: peterlubczynski → av

Comment 58

18 years ago
Should I follow any special step to reproduce the crash? If I just go to this 
URL it 
plainly works. Yesterday's debug build.

Comment 59

18 years ago
I think this is the same registration problem we used to have. Remove the 
Shockwave8 registry key under Macromedia under HKLM. That should force 
registration upon visiting that URL and afterwards you'll see the crash.

Comment 60

18 years ago
OK, I guess I need to clean the registry to trigger the registration process. 
Now I get a dialog box saying 'Shockwave error 7: An error occurred while 
communicating with Please try again later.' almost 

Comment 61

18 years ago
Arun Help!!!

Yes, I get the same thing now and it doesn't matter what the trigger testcase 
is. We need to be able to reproduce this to figure out what's wrong. Or, perhaps 
Macromedia can tell us what we are doing wrong?

I'll try changing my useragent string to 4.x, but who knows what their server 
will hand back????

Comment 62

18 years ago
Peter, I put breakpoints at every possible call to the plugin API and it looks 
like this message appears right after NPP_DestroyStream. Can you confirm?

Comment 63

18 years ago
Ug....once again...another stream problem....look at the output of NPSpy with 
6.0 compared with 4.0. Notice the incorrect buffer:

NPP_NewStream(0x3a3d540, 0x396aee8("application/x-director"), 0x38de340, TRUE, 
NPN_PostURLNotify(0x3a3d540, 0x547be41(""), 
00000000, 345, 0x54804b1("Content-ty..."), FALSE, 0x547beb0)
NPP_WriteReady(0x3a3d540, 0x38de340)
NPP_Write(0x3a3d540, 0x38de340, 0, 8192, 0x3ab2500("RIFX")))
NPP_WriteReady(0x3a3d540, 0x38de340)
NPP_Write(0x3a3d540, 0x38de340, 16384, 8192, 0x3ab2500("RIFX")))
NPP_NewStream(0x3a3d540, 0x37f44a0("application/x-director"), 0x396dd90, TRUE, 
NPN_PostURLNotify(0x3a3d540, 0x547c091(""), 
00000000, 345, 0x547c181("Content-ty..."), FALSE, 0x547f7e0)
NPP_WriteReady(0x3a3d540, 0x396dd90)
NPP_Write(0x3a3d540, 0x396dd90, 0, 8192, 0x3b48010("RIFX")))
NPP_WriteReady(0x3a3d540, 0x396dd90)
NPP_Write(0x3a3d540, 0x396dd90, 16384, 8192, 0x3b48010("RIFX")))
NPP_WriteReady(0x3a3d540, 0x38de340)
NPP_Write(0x3a3d540, 0x38de340, 16384, 8192, 0x3ab2500("%G`¹=œG...")))
NPP_WriteReady(0x3a3d540, 0x38de340)
NPP_Write(0x3a3d540, 0x38de340, 32768, 8192, 0x3ab2500("%G`¹=œG...")))
NPP_WriteReady(0x3a3d540, 0x396dd90)
NPP_Write(0x3a3d540, 0x396dd90, 16384, 8192, 0x3b48010("%G`¹=œG...")))
NPP_WriteReady(0x3a3d540, 0x396dd90)
NPP_Write(0x3a3d540, 0x396dd90, 32768, 8192, 0x3b48010("%G`¹=œG...")))
NPP_WriteReady(0x3a3d540, 0x38de340)
NPP_Write(0x3a3d540, 0x38de340, 32768, 8192, 0x3ab2500("Š£€öðº+‘k—...")))
NPP_WriteReady(0x3a3d540, 0x38de340)
NPP_Write(0x3a3d540, 0x38de340, 49152, 8192, 0x3ab2500("Š£€öðº+‘k—...")))
NPP_WriteReady(0x3a3d540, 0x396dd90)
NPP_Write(0x3a3d540, 0x396dd90, 32768, 8192, 0x3b48010("Š£€öðº+‘k—...")))
NPP_WriteReady(0x3a3d540, 0x396dd90)
NPP_Write(0x3a3d540, 0x396dd90, 49152, 8192, 0x3b48010("Š£€öðº+‘k—...")))
NPP_WriteReady(0x3a3d540, 0x396dd90)
NPP_Write(0x3a3d540, 0x396dd90, 49152, 8192, 0x3b48010("µþæ®=sFƒ[...")))
NPP_WriteReady(0x3a3d540, 0x396dd90)
NPP_Write(0x3a3d540, 0x396dd90, 65536, 8192, 0x3b48010("µþæ®=sFƒ[...")))
NPP_WriteReady(0x3a3d540, 0x396dd90)

Comment 64

18 years ago
I think I know what the problem is, my fault. Looking at 
nsPluginStreamListenerPeer::OnDataAvailable(), we are calling the modified ODA 
for RequestReads instead of the old one and that causes the buffer to get way 
out of whack. No wonder there are problems with all sorts of plugins. I should 
have never added that. 

The solution here is to fix the ODA so that it can take regular and byte range 
streams, but remember that the public interface changed. We should really 
try to use the old one pull the specific byte range info out in the 
listener's ODA. 

Andrei, now that you are back, can you take a look at what's going on there. Bug 
82415 may help. It hasn't been the same since all the RequestRead stuff went in.

Comment 66

18 years ago
sr=mscott on the one liner assuming you can get an r= =).

Comment 67

18 years ago

Comment 68

18 years ago

Comment 69

18 years ago
Patches in the trunk and branch....

Okay, so now it doesn't crash but it says "connection refused" but at least it's 
doing the right thing. 

Comment 70

18 years ago
peterl, as i've maintained before, you rock!  this 'connection refused'
business: could it be caused by the general block that macromedia
has put on us?  shall i be evangelizing to circumvent this?

Comment 71

18 years ago
It is still likely some streaming issues: we don't give them what they expect. 
Just a feeling.

Comment 72

18 years ago
Hey!! This works!! On Win32....just fine in mozilla trunk nightlies. Get the 
lastest bits of the branch once they respin to test.


18 years ago
Whiteboard: rtm stopper

Comment 73

18 years ago
Shrirang, can you confirm and mark appropriately?

Comment 74

18 years ago
I did not crash on windows, however the error message did come up once I 
dismissed it, the registration proceeded fine and ther was no crash on the 
welcome page. On mac, however, I do not see the crash but registration does not 
proceed beyong the error message (it keeps popping up). This is the same status 
I had reported in bug 35916 here (2001-04-24 15:41). Cc : dshultz (macromedia 
qa) to see what he is seeing. 

Comment 75

18 years ago
Trying with a fresh build on my Win32 machine, I did not crash but this did not
work. Shockwave froze during registration, however, did not crash. Fiddling
around with the back/forward and reload buttons seemed to fix everything without
a crash or restart.

Andrei, this smells to me like the same problem as in reload.

Peter G: Mozilla has a new performance feature that creates the loading page
off-screen before destroying the old page (and instance). Do you think Shockwave
is effected by that?

Comment 76

18 years ago
Now we have bug 85334. Looks like this is it.

Comment 77

18 years ago
Well, this doesn't FIXED and over to bug 85334.

Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 78

18 years ago
I don't think this one is fixed. Although NS6.1b1 is no longer crashing, the 
shockwave movie on the welcome page (or visiting page) fails to load. I was able 
to reproduce this bug on today's Mozilla build too (build 2001061504)

Steps to reproduce:
1. With Shockwave Player installed in NS6.1b1 or Mozilla, delete the following 
registry keys (this will force registration):

HKCU\Software\Macromedia\Shockwave 8\nextpingdate
HKCU\Software\Macromedia\Shockwave 8\sw702down
HKCU\Software\Macromedia\Shockwave 8\sw702installed
HKCU\Software\Macromedia\Shockwave 8\sw702allseen

2. Launch NS6.1b1 or Mozilla and go to:
3. Click through the registration process and wait for the browser to be 
redirected to the Welcome page.
Result: Shockwave movie fails to load on Wecome page.

Comment 79

18 years ago
well..isn't that 85334 now?

Comment 80

18 years ago
No, although the steps to reproduce both bugs are the same.

Comment 81

18 years ago
OK, so the crasher was averted, but I'm re-opening this based on John Pfeiffer's
comments.  Peter L, is this related to bug 85334 or are they distinct as John
Pfeiffer says?
Resolution: FIXED → ---

Comment 82

18 years ago
I don't care if you keep bug 85334 or this one open (although we don't crash 
anymore and I like 85334 better).

From my observations, there seems to be two problems, both of which I outline in 
bug 85334. Basically, both have to do with plugin streams and WriteReady. 
Basically, IMO, ns4xPluginSreamListener::ODA needs to be completely re-written.

Macromedia: does the install do a navigator.plugins.refresh(1)? Arun, if so, 
that's yet another one that needs fixin'.


Comment 83

18 years ago
Arun, if you could lobby to make bug 85334 an rtm stopper, then I think it would 
be better to close this one, because 85334 covers the remaining issues.

Comment 84

18 years ago
Closing as bug 85334 is now marked an rtm stopper.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 85

18 years ago
marking this verif get off 0.9.2 radar. bug 85334 is the latest one
for the new issue.

Comment 86

18 years ago
In answer to "does the install do a navigator.plugins.refresh(1)" from "Peter 
Lubczynski 2001-06-18 15:28", Shockwave does not use NPN_ReloadPlugins(). Under 
some conditions (opening multiple windows containing shockwave during 
download), it will go an NPN_GetUrl() on "javascript:window.history.go(0)" 
after the installation is complete.

One oddity, possibly related to this bug. np32dsw.dll, in the plugins folder, 
implements the plugin entry points (NP_GetEntryPoints, NP_Initialize and 
NP_Shutdown) by forwarding them to another plugin. During normal operation, the 
second plugin is Plugin.dll in the Shockwave 8 folder. During updating, the 
second plugin is PluginPing.dll, which handles all the installation, 
registration, etc. When updating is complete, PluginPing.dll loads Plugin.dll, 
re-directs further netscape calls to Plugin.dll. Huh?? In NP_GetEntryPoints, 
netscape passes (NPPluginFuncs* pFuncs), the vector of functions it uses to 
invoke methods on the plugin. By forwarding NP_GetEntryPoints() to 
PluginPing.dll, netscape gets reference's to PluginPing's version of 
NPP_WriteReady, NPP_Write, etc. But PluginPing.dll cache's pFuncs, and when 
it's done, it calls Plugin.dll's NP_GetEntryPoints with the cache'd pFuncs, so 
at this late date (right about when the welcome page is shown), we overwrite 
the table. This has always worked, but if, for instance, NS6.0 passed us a 
pointer to a struct on the stack, the original stack has long since vanished 
and this write to struct will not be kosher. Furthermore, if NS6.X doesn't 
always use the original struct when making plugin function calls (for instance, 
if it caches individual function pointers), then this will also cause problems.

Hopefully, this is useful info, rather than a bunch of confusing spam. And 
speaking of spam, is another else excited about the re-release of "The Holy 

Comment 87

18 years ago
Ahh...Peter G: is this what you were referring to:

I bet this is the problem as why NP_Write() keep returning Zero, even with my
latest patches, because it's the wrong one.

cc:ing Brian Nesse for insight on how 4.x did this.....<I'm going to check that
code now>
It appears that both callback tables (NPPluginFuncs and NPNetscapeFuncs) are
both members of ns4xPlugin. The NPNetscapeFuncs are a static member, the
NPPluginFuncs are per ns4xPlugin instance. This is functionally the same as 4.x
(the NPNetscapeFuncs were simply a static global instead of a static member.)

Comment 89

18 years ago
Per "  2001-06-22 10:34", shockwave overwriting members of 
the (NPPluginFuncs *) at a later date won't be a problem, so I apologise for 
the unnecessary noise in the bug report.
You need to log in before you can comment on or make changes to this bug.