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)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: kcunningham, Assigned: serhunt)
References
()
Details
(Keywords: crash, shockwave, Whiteboard: rtm stopper)
Attachments
(6 files)
1.01 KB,
text/html
|
Details | |
1.83 KB,
text/plain
|
Details | |
2.82 KB,
patch
|
Details | Diff | Splinter Review | |
5.87 KB,
image/jpeg
|
Details | |
347 bytes,
patch
|
Details | Diff | Splinter Review | |
757 bytes,
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
Reporter | ||
Updated•24 years ago
|
Updated•24 years ago
|
Assignee: av → peterl
OS: Windows 98 → Mac System 9.x
QA Contact: shrir → peterl
Comment 2•24 years ago
|
||
OS:Mac ,reassign:peterl
Comment 3•24 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.
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>
Comment 9•24 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.
Status: NEW → ASSIGNED
Comment 10•24 years ago
|
||
right, there are 2 separate bugs here. I'll submit the crasher bug on the
shockwave frameset page separately
Comment 11•24 years ago
|
||
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.
Comment 12•24 years ago
|
||
Okay, I got a consistant stack, but it's very messy. I could use some help on
this one.
Comment 13•24 years ago
|
||
Comment 14•24 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
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?
Comment 15•24 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•24 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•24 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•24 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•24 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 21•24 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•24 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 24•24 years ago
|
||
Changing peterl-retired to peterlubczynski
Assignee: peterl-retired → peterlubczynski
Status: ASSIGNED → NEW
Comment 25•24 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.
(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.
Comment 26•24 years ago
|
||
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
Comment 27•24 years ago
|
||
Nom. nsbeta1. Shockwave backward compatibility bug, and high-quality plug-in
support is a priority for embedded applications.
Keywords: nsbeta1
Comment 28•24 years ago
|
||
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•24 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.
Updated•24 years ago
|
Target Milestone: mozilla0.8 → mozilla0.9
Comment 30•24 years ago
|
||
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•24 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•24 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.
Status: NEW → ASSIGNED
QA Contact: peterl-retired → shrir
Comment 33•24 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•24 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•24 years ago
|
||
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.
Assignee | ||
Comment 36•24 years ago
|
||
Assignee | ||
Comment 37•24 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•24 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.
Assignee | ||
Comment 39•24 years ago
|
||
I saw this before I applied the patch, but it works for me as a champ with it.
Comment 40•24 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.
Assignee | ||
Comment 41•24 years ago
|
||
Would you give me the exact steps to reproduce the crash? Including urls.
Comment 42•24 years ago
|
||
Comment 43•24 years ago
|
||
Comment 44•24 years ago
|
||
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.
Assignee | ||
Comment 45•24 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•24 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
Status: ASSIGNED → NEW
Assignee | ||
Comment 47•24 years ago
|
||
peterl gave his r= in private e-mail.
Comment 48•24 years ago
|
||
looks good, sr=waterson
Assignee | ||
Comment 49•24 years ago
|
||
Checked in --> fixed
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 50•24 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.
Status: RESOLVED → VERIFIED
Comment 51•24 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.
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 → ---
Comment 52•24 years ago
|
||
Comment 53•24 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•24 years ago
|
||
this has resurfaced and really should be an m0.9.1 stopper.
Keywords: mozilla0.9.1
Comment 55•24 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:
http://www.shockwave.com/bin/shockwave/account/welcome/welcome.jsp
Unfortunately, yes :-(
Comment 56•24 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
Status: REOPENED → NEW
Target Milestone: --- → mozilla0.9.2
Assignee | ||
Comment 58•24 years ago
|
||
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.
Comment 59•24 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.
Assignee | ||
Comment 60•24 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 www.macromedia.com. Please try again later.' almost
immediately.
Comment 61•24 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????
Assignee | ||
Comment 62•24 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•24 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,
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)
Comment 64•24 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 65•24 years ago
|
||
Comment 66•24 years ago
|
||
sr=mscott on the one liner assuming you can get an r= =).
Assignee | ||
Comment 67•24 years ago
|
||
r=av
Comment 68•24 years ago
|
||
a=chofmann
Comment 69•24 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•24 years ago
|
||
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?
Assignee | ||
Comment 71•24 years ago
|
||
It is still likely some streaming issues: we don't give them what they expect.
Just a feeling.
Comment 72•24 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.
Updated•24 years ago
|
Whiteboard: rtm stopper
Assignee | ||
Comment 73•24 years ago
|
||
Shrirang, can you confirm and mark appropriately?
Comment 74•24 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•24 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?
Assignee | ||
Comment 76•24 years ago
|
||
Now we have bug 85334. Looks like this is it.
Comment 77•24 years ago
|
||
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
Comment 78•24 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:
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.
Comment 79•24 years ago
|
||
well..isn't that 85334 now?
Comment 80•24 years ago
|
||
No, although the steps to reproduce both bugs are the same.
Comment 81•24 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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 82•24 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'.
Assignee | ||
Comment 83•24 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.
Assignee | ||
Comment 84•24 years ago
|
||
Closing as bug 85334 is now marked an rtm stopper.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 85•24 years ago
|
||
marking this verif again..to get off 0.9.2 radar. bug 85334 is the latest one
for the new issue.
Status: RESOLVED → VERIFIED
Comment 86•24 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
Grail"?
Comment 87•24 years ago
|
||
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>
Comment 88•24 years ago
|
||
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•24 years ago
|
||
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.
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•