Closed Bug 58128 Opened 24 years ago Closed 24 years ago

crash on visiting page with Shockwave content after SW registration

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: kcunningham, Assigned: serhunt)

References

(
URL
)

Details

(Keywords: crash, shockwave, Whiteboard: rtm stopper)

Attachments

(6 files)

test case, will crash mozilla
(deleted), text/html
Details
stack trace of crash
(deleted), text/plain
Details
patch to fix the problem
(deleted), patch
Details | Diff | Splinter Review
[script error] Shockwave dialog
(deleted), image/jpeg
Details
small patch to check for mStarted
(deleted), patch
Details | Diff | Splinter Review
patch to fix my mistake (one liner)
(deleted), patch
Details | Diff | Splinter Review 
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
Shockwave.com or macromedia.com)(you have to launch browser and go to a
shockwave game to continue install process)
2. Complete registration.
Results: The welcome movie page at
http://www.shockwave.com/bin/shockwave/account/welcome/welcome.jsp 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
Keywords: rtm, shockwave
Is it Mac only? If so, please update OS appropriately.
Assignee: av → peterl
OS: Windows 98 → Mac System 9.x
QA Contact: shrir → peterl
OS:Mac ,reassign:peterl
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
seems like this is a critical bug to fix for rtm
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac System 9.x → All
Priority: P3 → P1
Hardware: PC → All
the real problem url seems to be:
http://sdc.shockwave.com/shockwave/download/frameset.fhtml?application/x-director

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/http://home.netscape.com/download/">Netscape</a> or <a
href="/OUTGOING/http://www.microsoft.com/windows/ie/">Internet Explorer</a>
browser.
</body> </noframes> </html>
Attached file test case, will crash mozilla (deleted) — 

  

  



    
    

    
  
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.

  

  


Status: NEW → ASSIGNED

    
    

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

  

  



    
    

    
  
pollmann:  can you confirm whether this is a frameset bug, or bad source from
macromedia?

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

  

  



    
    

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

  

  



    
    

    
  

      
      
      
      

        Attached file
          
        stack trace of crash (deleted)
        — 
      

    


  

  

  



    
    

    
  
Okay, I've narrowed down the problem.

First, to reproduce:
1) Delete the Entire Shockwave 8 key in the HKCU/Software/Macromedia in the 
registry
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?

  

  



    
    

    
  
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.

  

  



    
    

    
  
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?

  

  



    
    

    
  
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.

  

  



    
    

    
  
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.

  

  



    
    

    
  
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]

    
    

    
  
Adding [rtm-]

  

  


Whiteboard: [need minus] → [rtm-]

    
    

    
  
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. 

  

  


URL: http://www.shockwave.com/bin/shockwav... → http://poppy.macromedia.com/netlanski...
Keywords: rtm
Summary: crash at sw welcome center page after registration. → crash on visiting page with Shockwave content after SW registration
Whiteboard: [rtm-]

    
    

    
  
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

  

  



    
    

    
  
Setting milestone to Mozilla 0.8.

  

  


Target Milestone: --- → mozilla0.8

    
    

    
  
Changing peterl-retired to peterlubczynski

  

  


Assignee: peterl-retired → peterlubczynski
Status: ASSIGNED → NEW

    
    

    
  
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.
(http://devedge.netscape.com/docs/manuals/communicator/plugin/init.htm#Shutdown)

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 
re-created. 

  

  



    
    

    
  
The new plugin API states that the plugin remains in memory so Shutdown probably 
shouldn't be called for those plugins.

http://www.mozilla.org/docs/plugin.html#benefit


  

  



    
    

    
  
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?

  

  



    
    

    
  
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.

  

  



    
  
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...


  

  



    
    

    
  
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.

  

  



    
    

    
  
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.

  

  


Status: NEW → ASSIGNED
QA Contact: peterl-retired → shrir

    
    

    
  
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. 

  

  



    
    

    
  
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. 



  

  



    
    

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

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=25274

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.

  

  



    
  
Depends on: 45009

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch to fix the problem (deleted)
        — 
          — Splinter Review
      

    


  

  

  



    
    

    
  
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.

  

  



    
    

    
  
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.


  

  



    
    

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

  

  



    
    

    
  
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.

  

  



    
    

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

  

  



    
    

    
  

      
      
      
      

        Attached image
          
        [script error] Shockwave dialog (deleted)
        — 
      

    


  

  

  



    
    

    
  


  

  

  



    
    

    
  
I've been using:

http://poppy.macromedia.com/netlanski/files/Movie/mudballdcrDoc.html

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.

  

  



    
    

    
  
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.

  

  



    
    

    
  
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
Status: ASSIGNED → NEW

    
    

    
  
peterl gave his r= in private e-mail.

  

  



    
    

    
  
looks good, sr=waterson

  

  



    
    

    
  
Checked in --> fixed

  

  


Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
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.

  

  


Status: RESOLVED → VERIFIED

    
    

    
  
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.
Registers:
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 


  

  


Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

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

  

  



    
    

    
  
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 → ---

    
    

    
  
this has resurfaced and really should be an m0.9.1 stopper.

  

  


Keywords: mozilla0.9.1

    
  
Blocks: 35916

    
    

    
  
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:
http://www.shockwave.com/bin/shockwave/account/welcome/welcome.jsp
Unfortunately, yes :-(


  

  



    
    

    
  
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
Status: REOPENED → NEW
Target Milestone: --- → mozilla0.9.2

    
    

    
  
Over to AV...welcome back :)

  

  


Assignee: peterlubczynski → av

    
    

    
  
Should I follow any special step to reproduce the crash? If I just go to this 
URL http://www.shockwave.com/bin/shockwave/account/welcome/welcome.jsp it 
plainly works. Yesterday's debug build.

  

  



    
    

    
  
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.

  

  



    
    

    
  
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 www.macromedia.com. Please try again later.' almost 
immediately.

  

  



    
    

    
  
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????

  

  



    
    

    
  
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?

  

  



    
    

    
  
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, 
NP_NORMAL)
NPN_PostURLNotify(0x3a3d540, 0x547be41("http://pinger.macromedia.com/"), 
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, 
NP_NORMAL)
NPN_PostURLNotify(0x3a3d540, 0x547c091("http://pinger.macromedia.com/"), 
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)

  

  



    
    

    
  
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.

  

  



    
    

    
  


  

  

  



    
    

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

  

  



    
    

    
  
r=av

  

  



    
    

    
  
a=chofmann

  

  



    
    

    
  
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. 

  

  



    
    

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

  

  



    
    

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

  

  



    
    

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

  

  



    
  
Whiteboard: rtm stopper

    
    

    
  
Shrirang, can you confirm and mark appropriately?

  

  



    
    

    
  
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. 

  

  



    
    

    
  
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?

  

  



    
    

    
  
Now we have bug 85334. Looks like this is it.

  

  



    
    

    
  
Well, this doesn't crash...so....marking FIXED and over to bug 85334.



  

  


Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
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:
http://poppy.macromedia.com/~cmckeon/content/shockwavemovie.html
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.



  

  



    
    

    
  
well..isn't that 85334 now?

  

  



    
    

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

  

  



    
    

    
  
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?

  

  


Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
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'.



  

  



    
    

    
  
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.

  

  



    
    

    
  
Closing as bug 85334 is now marked an rtm stopper.

  

  


Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
marking this verif again..to get off 0.9.2 radar. bug 85334 is the latest one
for the new issue.

  

  


Status: RESOLVED → VERIFIED

    
    

    
  
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 
Grail"?


  

  



    
    

    
  
Ahh...Peter G: is this what you were referring to:
http://lxr.mozilla.org/seamonkey/source/modules/plugin/nglsrc/ns4xPlugin.cpp#112

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.)

  

  



    
    

    
  
Per "bnesse@netscape.com  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.

  

  



    
  
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: