Closed Bug 57012 Opened 24 years ago Closed 23 years ago

POST data has garbage during Shockwave Registration

Categories

(Core :: Networking: HTTP, defect, P1)

Product:
Core
Component:
Networking: HTTP
Platform:
PowerPC
Mac System 8.6
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.8

People

(Reporter: shrir, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: shockwave) 

Mac branch build 2000101608
Plugins : shockwave flash 5.0 (comes with installation)
Macromedia shockwave player ABSENT

Steps to recreate problem :

1 Go to hgttp://www.shockwave.com
2 It should take you to the download url mentioned above
3 Go thru the installation steps
4 Launch browser (it shud launch automatically after install)
5 Type "about:plugins" in the url bar
6 Check to see Shockwave player 8.0 and Flash 5.0 listed( which they shud)
7 Now go to http://www.shockwave.com and click on 'Games'-> 'Arcade 
  Action'->'Delirium'
8 Observe that the bottom tab of the game appears but the area where the 
  shockwave game should appear, appears blank.
9 Out of 4 machines, only once did a shockwave update dialog pop up and on 
  clicking on it, the browser crashed. Attached below is the stack trace.
10 On 4.x, the update dialog pops up and proceeds with the update and loads the   
game fine.
11 Now this also starts working on 6.0(shockwave content loads and works great). 
So unless the update is done (using 4.x), shockwave does not work.

Bug 35915 was the one filed for shockwave install, so am assigning this to 
pchen. Pls reassign if you think it's not yours. Thx.
reassign: pchen 

Stack Trace:


 Call Stack:    (Signature = Shockwave Flash NP-PPC + 0x14b44 (0x1e2aaae4) 
f4eceffb) 
     
   Shockwave Flash NP-PPC + 0x14b44 (0x1e2aaae4) 
                                                      
     
   Shockwave Flash NP-PPC + 0x150bc (0x1e2ab05c) 
                                                      
     
   Shockwave Flash NP-PPC + 0x3cf58 (0x1e2d2ef8) 
                                                      
     
   Shockwave Flash NP-PPC + 0xd364 (0x1e2a3304) 
                                                      
     
   Shockwave Flash NP-PPC + 0x41bb8 (0x1e2d7b58) 
                                                      
     
   ns4xPluginStreamListener::OnStopBinding() 
                                                     [ns4xPluginInstance.cpp, 
line 314]
     
   nsPluginStreamListenerPeer::OnStopRequest() 
                                                     [nsPluginHostImpl.cpp, line 
1294]
     
   nsHTTPFinalListener::OnStopRequest() 
                                                     
[nsHTTPResponseListener.cpp, line 1157]
     
   InterceptStreamListener::OnStopRequest() 
                                                     [nsCachedNetData.cpp, line 
1206]
     
   nsHTTPChannel::ResponseCompleted() 
                                                     [nsHTTPChannel.cpp, line 
1895]
     
   nsHTTPServerListener::OnStopRequest() 
                                                     
[nsHTTPResponseListener.cpp, line 728]
     
   nsOnStopRequestEvent::HandleEvent() 
                                                     [nsAsyncStreamListener.cpp, 
line 301]
     
   nsStreamListenerEvent::HandlePLEvent() 
                                                     [nsAsyncStreamListener.cpp, 
line 97]
     
   PL_HandleEvent() 
                                                     [plevent.c, line 580]
     
   PL_ProcessPendingEvents() 
                                                     [plevent.c, line 513]
     
   nsEventQueueImpl::ProcessPendingEvents() 
                                                     [nsEventQueue.cpp, line 
356]
     
   nsMacNSPREventQueueHandler::ProcessPLEventQueue() 
                                                     [nsToolkit.cpp, line 134]
     
   nsMacNSPREventQueueHandler::RepeatAction() 
                                                     [nsToolkit.cpp, line 99]
     
   Repeater::DoRepeaters() 
                                                     [nsRepeater.cpp, line 119]
     
   nsMacMessagePump::DispatchEvent() 
                                                     [nsMacMessagePump.cpp, line 
424]
     
   nsMacMessagePump::DoMessagePump() 
                                                     [nsMacMessagePump.cpp, line 
253]
     
   nsAppShell::Run() 
                                                     [nsAppShell.cpp, line 110]
     
   nsAppShellService::Run() 
                                                     [nsAppShellService.cpp, 
line 406]
     
   Netscape 6 + 0x37c8 (0x1f294d28) 
                                                      
     
   Netscape 6 + 0x3fac (0x1f29550c) 
                                                      
     
   Netscape 6 + 0x14274 (0x1f2a57d4)
Assignee: av → pchen
rtm
Keywords: rtm
I havn't looked too closely at the code, but the fix for this could possibly be 
the same as the one for 54205. In that bug, we were passing a null MIME type 
sometimes and the plugin didn't like it. 

This stack trace also looks similar to the ones from IML32.DLL which ranked #10 
on talkback reports. Adding crash and shockwave keywords and cc:ing ekrock
Keywords: crash, shockwave
We bundle only the Flash plug-in with Netscape 6, not the Shockwave plug-in.
Miriam, could you please explain to us ASAP (a) what *should* be happening here,
and (b) what the user impact of not fixing this would be?
Reassinging to av@netscape.com since he is listed as plugin component owner,
which could be incorrect, but that's what the web pages shows. Bug 35915 had
nothing to do with the plugin or the installer; mozilla wasn't calling StuffIt
Expander to decode the file. Therefore, the installer wasn't an executable that
you could "double-click".
Assignee: pchen → av
Assignee: av → sdagley
Whiteboard: [rtm need info]
Reassigning to sdagley. Steve, would it be possible for you to fix this crasher
for RTM?
I think we need Macromedia's help on this one.  I'm not crashing but I am geting 
fairly useless Welcome to Shockwave! window which appears to do nothing once I 
click the Next> button.  This window is coming up from a seperate app named 
"ShockwaveDownload" which is installed in a Macromedia folder in my extensions 
folder.  I can only guess at what the app is trying to do (download something 
from shockwave.com?) and have no idea why it'd be crashing Mozilla.

Peter Grandmaison <grandma@macromedia.com> is one of the Shockwave developers 
over at Macromedia and was very helpful in narrowing down another crasher of 
mine. Perhaps he could be of assistance.
Add'l info from shrir:

Allow me to explain what I meant in the bug summary. Even after I install 
shockwave 8 and flash 5.0 on seamonkey, visiting the shockwave games page opens 
up a "Installing shockwave update" dialog and does some installation(but this is 
not happening every time, sometimes a blank space is seen in place of the plugin 
and nothing happens). I would not expect this to happen (since both plugins are 
present in the browser). And, yes, the current installer has recogznized the NS6 
browser installation on my hard disk quite a few times. I am not sure how this 
happened but I am sure about this.

Add'l info from sdagley:
He tested in his own branch build which contains the fix for Mac plug-ins always 
looking in the correct "plug-ins" folder. He doesn't think that's relevant 
thought. FYI FWIW.

Miriam: sdagley believes that the Shockwave plug-in is causing a separate 
Shockwave update application to launch and run in its own window. What can you 
tell us about that app?

Marking [rtm-] and Future because we're unable to find a way to reliably 
reproduce this at the moment. If someone can find a reliable way to reproduce 
this in time, we'll re-evaluate that decision.
Keywords: qawanted
Whiteboard: [rtm need info] → [rtm-][sdagley can't reproduce the crash]
Target Milestone: --- → Future
I urge you to take another crack at this one because I think it could be quite 
bad for Shockwave. Steve, I was able to reproduce this easily and it was quite 
difficult to get Shockwave actually working on a fresh install.

Here are the steps which I tried:
1) Get a CLEAN build from sweetlou. I used the commercial MN6 from 10/18. Create 
a clean profile as well.
2) Go to: http://www.shockwave.com/
3) Do the install as indicated (download, quit Moz, install Shock)
4) When installing, it'll find the clean build you downloaded. Install to there.
5) When Moz starts up, try out your install by going to http://www.shockwave.com
6) Click on "Games" and try to play a game under "Actions", let's say "Spy 
Hunter" (I don't think it matters which one)
7) Notice the game doesn't load, only a white/black rect

Expected Results: The game should play (but it does crash later, but that's 
another bug).

Every combination of copying plugins from other installs or creating new 
profiles didn't work. Even renaming the folder (plugins vs. plug-ins) didn't 
work. I couldn't get Shockwave to work at all!!!

So, I deleted everything to start CLEAN once again. I repeated the above steps, 
EXCEPT in step #4, duing the Shockwave install, I pointed to my Nav 4.x folder. 
After the install, I manually copied the plugins from the 4.x folder to the 
clean Moz plugins folder. Went back to the games page in Moz, and it worked!! 

I agree that this is a problem with their installer, but we should handle 
this better since a simple copy works better than an install. This workaround is 
quite difficult and this is the only way I've been able to get a working 
Shockwave install. If this isn't fixed for rtm, we need to at least add a 
really good rel note or perhaps ask Macromedia to fix thier installer. Removing 
minus to trigger re-evaluation.
Whiteboard: [rtm-][sdagley can't reproduce the crash] → [rtm][sdagley can't reproduce the crash]
Yes, basically the browser(6.0) does not perform the 'Step 3' as mentioned on 
the page http://www.shockwave.com/bin/shockwave/download/fs.jsp?id=shockwave 
and that's why the installation remains incomplete..i guess.
Like I said before, we need input from the Macromedia/Shockwave folks on this.  
There's some sort of interaction going on between the Shockwave plugin, the 
ShockwaveDownload app it launches and Mozilla.  Since we only have source to the 
latter debugging isn't practical (sorry, I don't read PPC assembly)

cc: mtomlin
*** Bug 56171 has been marked as a duplicate of this bug. ***
*** Bug 57202 has been marked as a duplicate of this bug. ***
Comments from bug 57202 posted by: kcunningham@macromedia.com

1.Set the appropriate pinger. Run Shockwave shim installer (any version).
2. Click the "Next" button on the "Welcome to Shockwave" dialogue.
Results: Process hangs.
Expected:Process should continue through installation/registration process

---or---

1. Run any full pinging Shockwave installer.
2. Run Netscape 6 PR3 and view any Shockwave content.
3. Click the "Next" button on the "Welcome to Shockwave" dialogue.
Results: Process hangs.
Expected:Process should continue through installation/registration process

10/5/2000   John Pfeiffer: The Macintosh version of Netscape 6 PR3 appears to be
sending corrupted data to the pingserver. I used netcat to examine the data that
is sent to the pinger by different versions of Netscape on different platforms.
The Netscape 6 PR3 Mac example clearly shows corrupted data. Also, if you use a
specific pinger on parsons, the errors log will show an "invalid data" error for
that transaction.
John Pfeiffer one of the installation engineers at Shockwave.com reported this
bug in our bugbase (63045) so he is the best contact for questions about testing
and fixing! Please ad him to the CC list on this issue! Thanks, Kelly

Meredith/Kelly,

Is this the same as bug 35916 which will be fixed when Macromedia updates their 
Shockwave installer?
Peter,
No, this bug is not related to bug 35916. The reason the web install fails (on 
the Mac) is that the ShockwaveDownload app is unable to get a response from our 
pingserver (the pingserver is basically a webserver). The ShockwaveDownload app 
uses POST to send information to the pingserver. It appears that Netscape 6 PR3 
on the Mac is causing a corruption in the data that is sent to the pingserver. 
To rule out a possible bug in the pingserver, I just started a netcat session, 
and forced the ShockwaveDownload app to ping the server and port I had specified 
in the netcat session. I noticed corrupted characters in the Mac transaction. I 
will post my results below.

*************************** Mac Netscape 6 PR3 *****************************

kidcreole% nc -l -p 1234
POST / HTTP/1.1
Cookie: visitor_id=808f2038.38f767d9.20427; vid=80ab5865.8253.3934b74c.830; 
macromedia_member_id=18196010,6bba338fe78f5d4d6b8194d3354221c1; site_pref=v1; 
uvisitor_id=80a106a3.391909fd.2883; popup_703_total=1
Host: intranet.shockwave.com:1234
User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) Gecko/20000929 
Netscape6/6.0b3
Accept: */*
Accept-Language: en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive
Ø;¨EêˆÎxÜ©¥rÀ[=%»„•Li-ø.ø&ø2}¿NPîJðLðAðQðIðYð^ðN�.Îacˆ³ôö5‡N+¯ïYX(»ù5ûÉÍæ…xÚ•È1
!                                                                              
Â0<�ÂÊÃÓ°œAhÂx&d¡tåù³ÿ"ÞxÚÍQÁ
ÂèìÈ£ªN\âÔ„ŠÔú°±I"Óâ      Ãsp
                             �p
                               Æá°ê�˜š_º
                                        Ý2W­Lr`z’Iۗ¤ô9Ax…ÀQ—“pnWä
G/„”®ŒC©ÃÔñÿõ܇ubn—ÑpïÊ2�•dßö�^_¹)î×Êÿ8ÿžE‡üB 
@xÚkbhbØÏÐ4·iîþ¹Mÿšþíÿ×$Û$»_¶‰Dq"‡$�xÚ¥SKnÜ0
                                                                                          
R㦟E�ºé&�¶2ö,�‰t�.
                                                                                                             
t•E�~ŽÐ#´{ëd}´å™A�~Ð~0ÁGRâG1Æ(³l(µmß;9ˆß.O<+°i¹�AX²cßÁ­ã�²p$Ôæ9GÖ¦6KJ
                                              6WƒeÖ9_½d“ÈKçY†4 a„2PC]!A,
                                                                        
É•³P�¦¤WÅ´;¡”q¸+Õ
hrPe3=xtras,%3DoÅ0tAsset PPC,%3D 800197&file4=xtras,%3D SWA Streaming PPC 
Xtra,%3D 800196&file5=xtras,%3D SWA Decompression PPC Xtra,%3D 
800199&file6=xtras,%3D Sound Control,%3D 800203&file7=xtras,%3D NetLingo PPC 
Xtra,%3D 800196&file8=xtras,%3D NetFile PPC Xtra,%3D 800196&file9=xtras,%3D 
InetUrl PPC Xtra,%3D 800196&file10=xtras,%3D Multiusr,%3D 
800198&file11=xtras,%3D Font Xtra PPC,%3D 800196&file12=xtras,%3D Font Asset 
PPC,%3D 800196&file13=xtras,%3D Flash Asset PPC,%3D 800198&file14=xtras,%3D 
CBrowser PPC Xtra,%3D 800196&file15=xtras,%3D Shockwave Updater,%3D 
800196&package3=shockwave,%3D 800203&file16=shockwave,%3D SwSupportLib,%3D 
800196&file17=shockwave,%3D SwOnceLib,%3D 800196&file18=shockwave,%3D 
SwMenuLib,%3D 800196&file19=shockwave,%3D SwInit,%3D 800196&file20=shockwave,%3D 
ShockwaveDownload,%3D 800196&file21=shockwave,%3D ProjLib,%3D 
800196&file22=shockwave,%3D PluginPingLib,%3D 800196&file23=shockwave,%3D 
PluginLib,%3D 800203&file24=shockwave,%3D MacromediaRuntimeLib,%3D 
800196&file25=shockwave,%3D IMLLib,%3D 800203&file26=shockwave,%3D DPLib,%3D 
800196&package4=flash,%3D 800203&package5=shim,800196


***************************** Win Netscape 6 PR3 *******************************

kidcreole% nc -l -p 1234
POST / HTTP/1.1
Cookie: vid=80b2e9e1.28963.399cdefe.4402; auto_login=1; 
macromedia_member_id=31777949,e9419acb4527a7dd4c7db46a538135a3
Host: intranet.shockwave.com:1234
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20000929 
Netscape6/6.0b3
Accept: */*
Accept-Language: en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive
@--type: application/x-www-form-urlencoded
Content-length: 1383

action=update&protocol=2&registrationnumber=&machinetype=pc&mode=initial&pluginv
ersion=800196&os=nt&osversion=4.0&oslanguage=9&installtype=general800&product1=S
HW10D80&installstate=fullinstall&sampleperiod=0&uilanguage=en&worldregion=1&save
sattempted=&savescompleted=&package1=xtras,800203&file1=xtras,TextXtra.x32,80019
6&file2=xtras,Text 
Asset.x32,800197&file3=xtras,SWAStrm.x32,800196&file4=xtras,SWADCmpr.x32,800199&
file5=xtras,Sound 
Control.x32,800201&file6=xtras,QT3Asset.x32,800203&file7=xtras,NetLingo.x32,8001
96&file8=xtras,NetFile.x32,800196&file9=xtras,Multiusr.x32,800198&file10=xtras,M
acroMix.x32,800203&file11=xtras,INetURL.x32,800196&file12=xtras,Font 
Xtra.x32,800196&file13=xtras,Font Asset.x32,800196&file14=xtras,Flash 
Asset.x32,800198&file15=xtras,DirectSound.x32,800196&file16=xtras,CBrowser.x32,8
00196&file17=xtras,Shockwave 
Updater.x32,800196&package2=shockwave,800203&file18=shockwave,SwSupport.dll,8001
96&file19=shockwave,SwOnce.dll,800196&file20=shockwave,SwMenu.dll,800196&file21=
shockwave,SwInit.exe,800196&file22=shockwave,Proj.dll,800196&file23=shockwave,Pl
uginPing.dll,800196&file24=shockwave,Plugin.dll,800196&file25=shockwave,iml32.dl
l,800200&file26=shockwave,DynaPlayer.dll,800196&file27=shockwave,dirapi.dll,8001
96&file28=shockwave,Control.dll,800198&package3=obsolete,800203&package4=flash,8
00203&file29=flash,swflash.ocx,428000&package5=shim,800196

 
cc:'ing gagan since we may have a Necko problem on Mac

possible dup of bug 54081. I would let sdagley verify that.

I'd love to verify it but now I seem to have a completely different crash just 
trying to get to the test page.  I'm doing a new build to verify my tree is up to 
date.  Will post again when that's done.
Depends on: 58019
No longer depends on: 58019
Now I am not seeing the bug I reported in bug #58019 but I'm still not getting 
past clicking the "Next" button so maybe bug #54081 wasn't the answer.  Time to 
dig out the packet monitor at this end and make gagan watch what it's doing.

*** Bug 56171 has been marked as a duplicate of this bug. ***
*** Bug 56171 has been marked as a duplicate of this bug. ***
Changing [rtm] in Summary to [rtm need info]. Other bugs are being marked as
DUPs of this, but we're still unable to reproduce. Can anyone come up with a
reliable way to reproduce this?
Whiteboard: [rtm][sdagley can't reproduce the crash] → [rtm need info][sdagley can't reproduce the crash]
I have provided some Mac tools that will allow you to reproduce the netcat 
results I posted earlier. They are located at:
http://poppy.macromedia.com/~cmckeon/downloads/NetscapeToolsMac.sit

This package contains two tools. Just double click to execute them. The first 
one (ForcePing 8) can be used as is. The second one (SetPinger8) needs to be 
modified using a Mac resource editor. Use these tools after you have 
installed a full pinging vervion of Shockwave. See below.
1. ForcePing 8 (This just forces Shockwave to POST).
2. SetPinger8  (This sets the url and port that Shockwave should POST to. Edit 
the TEXT resource of SetPinger8 and set http://pinger.macromedia.com/ to the 
server and port of your netcat session. For instance:
http://someserver.netscape.com:1234/
I'm not familiar with netcat, which I assume is a PC tool for packet analysis, so 

I've been using Interarchy (the successor to OT Session Watcher) on the Mac.  It 

seems to agree with the earlier comment - i.e. the POST packet is screwed up.  

Unfortunately getting this data involves playing russian roulette with the 

shockwave.com website as >90% of the time I crash before I ever get to the 

Delerium page that triggers the upgrade.  Unfortunately, or fortunately depending 

on your point of view, shrir can't repro the problem on the optimized builds.  

right now I'm waiting on gagan to look at the POST packet as grabbed by 

Interarchy and an HTTP protocol log from Necko to see if he has any clues since I 

don't


The word from shrirang is that now we _are_ getting intermittent crashes with Mac 
optimized builds on the shockwave.com site so it's not debug specific.  I've 
asked him to log a seperate bug since this bug is for the registration failure 
which isn't related to the crash (or so I'm thinking)

And he did - see bug #58823

Steve,

Try increasing the amount of memory allocated to Mozilla to something large like 
50 Meg. By doing this, I didn't see the crash and as able to play the games. 
Actually, even the "update" seemed to work. I do recall the Shockwave installer 
changing Nav 4.x memory after install. The old installer probably doesn't know 
about "Mozilla". 
I was already running with a 26MB partition which should be plenty.  If it's not 
we've got serious problems as our memory allocators should grab memory out of 
system temp mem if there's not enough room in our own heap when they receive an 
allocation request.  Can anyone from Macromedia comment if the shockwave plugin 
is doing its own memory allocation?

The Shockwave Installer will increase the Preferred memory size of NS6 if it 
falls below a certain value. To verify this, set the Preferred size to that of 
the Minimum size before installing Shockwave.
Without a reviewed patch, or reproducible test case, we can't hold N6 RTM for
this. Marking [rtm-]
Whiteboard: [rtm need info][sdagley can't reproduce the crash] → [rtm-][sdagley can't reproduce the crash]
Can someone please explain what this bug is supposed to be? As far as I can 
determine this is either a) invalid or b) a duplicate of 56297.

I have downloaded and run the shockwave installer many times over the last 2 days 
and the only problem I can find is that it doesn't install into the Netscape 6 
directory without manually browsing to it... and this is beyond our ability to 
fix. This would make the bug invalid because the update DOES take place.

If this bug is supposed to refer to the fact that the Delirium doesn't run, then 
it is a duplicate of 56297 (which, in my opinion, is a duplicate of 56171 which 
was incorrectly marked as a duplicate of this bug.)

First of all, I think the "Platform" description on this bug is incorrectly set 
to "PC". It should be "Macintosh" as I have only experienced this bug on the 
Macintosh platform. I believe the source of this bug is that NS6 is corrupting 
the header during the POST operation. I captured and posted this corrupted 
header in my previous comments, including the header that is sent by NS6 on both 
PC and Mac for comparison purposes.
John, I concur that this is a Mac bug (changing Platform), and I have done all of 
my testing on the Mac. You indicate that the web install fails because 
"ShockwaveDownload app is unable to get a response from our 
pingserver." Is this after quitting browser and running the installer? I guess 
that because I successfully get the plugins installed into my plug-ins folder I 
am confused at to at what point in the process the bug is occuring.
Hardware: PC → Macintosh
This bug can be reproduced in a number of different ways. One way is to 
completely uninstall Shockwave, and follow steps 1 thru 3 in the "steps to 
recreate". Another way to reproduce this bug is, with Shockwave already 
installed, delete the Shockwave 8 Preferences file and try to view any Shockwave 
content.
Ok, the key here seems to be the deletion of the Shockwave 8 Prefs file. Now I 
get a dialog which pops up and says "You're getting the FREE Shockwave Player". 
Clicking on the "Next" button causes never ending network activity but does not 
connect to the server (which is what it apparently trying to do.) I can cancel 
out though... no crash. This seems like it could be a duplicate of 58128. 

Brian, Did you try Peter Lubczynski's suggestion of increasing the app partition 

to 50Meg before tring to register?   Not that I consider that a reasonable 

workaround but it could be we've got a memory corruption bug lurking somewhere.


Brian, I don't agree that this is a dupe of bug 58128 for the simple reason that 
bug 58128 occurs _after_ the registration process has been successfully 
completed. This bug prevents the registration process from occurring at all.
When you click on the "Next" button of the "You're getting the FREE Shockwave 
Player" dialog, here's what is happening behind the scenes:
1. Shockwave makes an API call to NPN_PostURLNotify()
2. NPN_PostURLNotify() sends corrupted header to pinger.
3. Pinger gets confused by corrupted header and does not respond to the client.
4. Shockwave waits for a response from the pinger.

I also agree with John. Bug 55128 is a crash that happens at the end of 
registration. I've narrowed it down to opening any Shockwave content after 
completion of registration and it happens on Win32 as well. But this bug is 
completely different, having to do with POSTing garabage right at the begining 
of registration. 
John, Peter, I concur... my mistake.

Steve, I have tried it with Memory allocation set to 50 Meg. This has no effect. 
Also noteworthy here... Netscape is no longer the frontmost application. The 
window I described previously is not a Netscape window, it belongs to the 
application "ShockwaveDownload" (which John refered to earlier. I didn't notice 
previously that Netscape wasn't frontmost. Heap corruption in our heap should not 
be the issue here (unless we are stomping on the NPN_PostURLNotify data.)

I'm now able to reproduce this bug pretty reliably by deleteing the Shockwave 8 
file in the Preferences folder.

Here are some comments from and e-mail from Peter Grandmaison from Macromedia 
that may help:
==========================================================
The installer you download contains a plugin called pluginping.dll which 
posts (via the browser) to macromedia to find out what files to download, 
and then streams the files individually (again through the browser). 
ShockwaveDownload is a bit of a red herring ... we cannot create a modal 
dialog for our download UI, as we need the host browser to dispatch events, 
but if we create a modeless window, then the host browser won't dispatch 
window events to our window (as the mac model requires your event loop work 
out which window receives the event and then to invoke a reasonable method 
to handle it), so we created a separate application called 
ShockwaveDownload just for the UI.

ShockwaveDownload does no processing ... it uses interapplication 
communication to sync it's ui with the download state, and to pass the 
registration information onto the plugin.

It appears to hang because it is waiting for the plugin to single the 
completion of the first step of installing, receiving a reply to the post, 
which isn't coming because the post has been munged.

Can you try breaking on NPN_GetUrl(), and NPN_GetUrlNotify() and see 
whether the data passed to mozilla is correct?
Marking Mozilla0.8 and reassigning to peterl.
Assignee: sdagley → peterl
Severity: normal → major
Target Milestone: Future → mozilla0.8
I've stepped through _geturlnotify() and all the other plugin code which does 
the POST in the debugger and I don't see a problem. The POST data looks correct 
from the plugin side. In the debugger, the POST data does not look like John 
Pfeiffer's comment on 2000-10-23 of what the server gets. Also, StreamWatcher 
and OTSessionWatcher don't display that POST session for some reason so I can't 
verify John's output either. 

I think this is something the networking folks need to look at. 
Gagan, can you take a look at this one? It's very important for Macromedia.

Updating Summary and Keywords...
Changing URL to point to a page with Shockwave content
Changing Priority and Severity to Blocker as this blocks installation of 
Shockwave on Mac
Assignee: peterl → darin
URL: http://www.macromedia.com/shockwave/d... → http://poppy.macromedia.com/netlanski...
Severity: major → blocker
Component: Plug-ins → Networking: HTTP
Keywords: crash, qawanted, rtm
Priority: P3 → P1
QA Contact: shrir → tever
Summary: Shockwave player update does not take place → POST data has garbage during Shockwave Registration
Whiteboard: [rtm-][sdagley can't reproduce the crash]
cc'ing gordon for mac expertise.
Bug 54081 was causing corruption for "large" data uploads. It is my guess that
since the bug is reported against NS6pr3, this may be fixed now.  Can someone
please verify against a recent nightly build.  I'd like to know if POST data is
still being munged.  Thanks!
I just tried this again with a fresh pull on my Mac and there still seems to be 
a problem somewhere in the POST phase. I tested with OT Session Watcher, and 
it's not picking up the POST session with postData beginning with 
"action=update&pro...." probably because it's still getting munged. I've tried 
stepping through with the debugger starting with ns4xPlugin::_posturlnotify but 
I got lost once I hit the netwerk code.

Can you step through this or watch the socket for that session? The fix for this 
would go into a possible 6.01 candidate. Thanks.
CCing pollmann and myself.
will take a look...

going to www.shockwave.com doesn't work though...
is there a direct URL to the installer?  thx!
You'll have to get and install Shockwave with Mac Nav 4.x. Once installed and 
working (verify with 4.x) visit any page with Shockwave content (like the 
URL testcase above) and you'll see the registration. To re-trigger registration, 
 delete the Shockwave Prefs file.
Oh, I forgot to say you need to then manually copy the Shockwave plugin from the 
4.x plugins folder to the Seamonkey one.
peter: I followed your instructions, and was able to get shockwave content
to run under netscape 6.0 RTM.  But, I was not prompted to register when I
first ran it under NS6.  I also do not see a Shockwave Pref file.  Where
should it be?  Thanks!
Check in the System Folder, in the Preferences. There should be a "Shockwave 8 
Preference" file. Delete that. Let me know if you can't find it.
Ok, the corruption always happens in the second packet after the Connection:
keep-alive header is sent.  This second packet corresponds to the temp file
created by layout's formpost code.  Here's a sample packet trace showing the
corruption:

Send data (256 bytes).
<00000000< POST / HTTP/1.1
<00000011< Host: pinger.macromedia.com
<0000002E< User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m18)
<00000066< Gecko/20001108 Netscape6/6.0
<00000084< Accept: */*
<00000091< Accept-Language: en
<000000A6< Accept-Encoding: gzip,deflate,compress,identity
<000000D7< Keep-Alive: 300
<000000E8< Connection: keep-alive

Send data (347 bytes).
<00000100< «00»«00»«02»«00»«00»«00»«06»«00»«00»«00»«00»«00»«00»«00»«04»«00»
<00000110< «01»li«00»ation/x-www-form-urlencoded
<00000131< Content-length: 276
<00000146<
<00000147< action=update&protocol=2&registrationnumber=&machinetype=mac&mod
<00000187< e=initial&pluginversion=800197&os=mac&osversion=8.6&oslanguage=0
<000001C7< &installtype=macrweb&product1=SHM10D80&installstate=&sampleperio
<00000207< d=0&uilanguage=en&worldregion=1&savesattempted=&savescompleted=&
<00000247< package1=shim,800197

The first packet is that generated by necko.  The second is from the start
of the temporary formpost file generated by layout/html/forms/nsFormFrame.cpp
In this case it is just the Content-type header that is getting corrupted.

Does anyone know how to locate this temporary file on the Mac filesystem.
Mozilla leaves this file around (which is a separate bug), but using the
Finder's File->Find option I couldn't locate it.  It would be nice to check
the contents of that file to see if it is ok.

CC:ing Eric Pollmann as I heard he was working with multi-part POST data and may 
know where this file is on the Mac.
Bug 15320 talks about this temporary file.
It turns out that we can POST data without first having a temporary formpost
file.  This is just used in some cases... apparently not in this case.  Once
I get a debug build I will be able to diagnosis this problem better.  Sorry
for the wild goose chase ;)
(sorry for the slow reply)

Yep, a temporary file is only generated by a multipart form post <form
method="post" enctype="multipart/form-data"> processed by the logic in
nsFormFrame.cpp, and not just a standard <form method="post">.  You can
determine if a temp file is created by setting a breakpoint in
nsFormFrame::ProcessAsMultipart(), and examine the data as it is being written
to the file.

If the post is not written to a file, you can examine the buffer that contains
the post data by examining 'data' in nsFormFrame::OnSubmit() after
ProcessAsURLEncoded() is called.
thanks eric!  investigating...
Nom. nsbeta1. Shockwave backward compatibility bug, and high-quality plug-in
support is a priority for embedded applications.
Keywords: nsbeta1
Darin,

Did you fix this? All of a sudden this is working.
I did not fix this... what build are you testing?
Well, if you didn't fix it, someone else did. This works pretty good now. Here
is a copy of my HTTP POST session:

Send 293 bytes.
<00000000< POST / HTTP/1.1  
<00000011< Cookie: MM_cookie=206.222.241.140.537979168255908  
<00000044< Host: pinger.macromedia.com  
<00000061< User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) 
<00000099< Gecko/20010124  
<000000A9< Accept: */*  
<000000B6< Accept-Language: en  
<000000CB< Accept-Encoding: gzip,deflate,compress,identity  
<000000FC< Keep-Alive: 300  
<0000010D< Connection: keep-alive  

Send 351 bytes.
<00000125< Content-type: application/x-www-form-urlencoded  
<00000156< Content-length: 276  
<0000016B<  
<0000016C< action=update&protocol=2&registrationnumber=&machinetype=mac&mod
<000001AC< e=initial&pluginversion=850152&os=mac&osversion=9.0&oslanguage=0
<000001EC< &installtype=macrweb&product1=SHM10D85&installstate=&sampleperio
<0000022C< d=0&uilanguage=en&worldregion=1&savesattempted=&savescompleted=&
<0000026C< package1=shim,850152  
<00000282<   

I'm using a pretty recent pull, just in the past few days. Has anything new gone
in lately? Do you have any idea why this started working all of a sudden? It'd
be good to check this on the MTEST builds as well. 

Marking FIXED.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I did a large networking checkin (bug 62566) which could have indirectly fixed
this, but I'm not sure.  Anyways... I like the sound of this being fixed.

adding keyword verifyme.
Keywords: verifyme
okay, I just verified this on the trunk build on mac and this works fine. 
However, this is not fixed on the branch (since this got automatically fixed by 
some checkin Darin made on the trunk which did not go in the branch as I can see 
from the bug that he fixed). Should this be reopened for the branch ?
Perhaps it should be reopened for the branch, but my patch for bug 62566 is
definitely not appropriate for the branch (it's way to big a change to necko).

I'm not even convinced that it was my patch that fixed things on the trunk.
It was probably a combination of things.
I agree with Darin. It was either something in Necko or a combination of things 
that fixed this but IMO, it's definitely too high-risk for the branch unless we 
could single out exactly what it was that fixed this.

Shrirang: In your e-mail to me you said you couldn't verify. Was that for the 
branch? But here you say you verified on the trunk. I hope this makes it clear.
i tried this again with the mac trunk (0418) . Had increased the memory 
allocated and had removed the shockwave prefs from system folder before I did 
this.
Steps:
1 Worked around the shockwave block and got the installer from their website 
  shockwave.com
2 The installer recognised ns6 on my desktop and proceeded with the 
  installlation 
3 The browser restarted with a blank page
4 I went to the test url above to complete the registration and load the movie
5 As soon as the registration update dialog opened up, another error dialog 
  opened in front of it saying" An error aoccured while contacting 
  www.macromedia.com. Pls try again later"

The browser just freezes after that. Works ok on windows (except for the known 
issue of the installer looking for 'netscape.exe'). reopening..
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
shrir: what build did you notice this on?
darin : 2001041809
I'm seeing this too, but I'm getting a hard crash after the error. This error is 
new, I havn't seen it before, perhaps a regression from recent check-ins. Trying 
to get Talkback to give me a trace but it crashed too.
I think this bug should be marked FIXED because in the HTTP session watcher, it's 
clear that the POST data does not have any garbage. In fact, the problem may be 
that Macromedia's Netscape Enterprise server is handing back a HTTP/1.1 302 Moved 
Temporarily for the welcome page. Please use bug 35916 for install problems or 
reopen if you think this is still a problem.

Send 734 bytes.
<00000000< GET /bin/shockwave/visitor/welcome.jsp?first=sdfafs&last=safsaf&
<00000040< email=asffs%40safas.com&pref=y&lang=en&age=0&url=http%3A%2F%2Fpo
<00000080< ppy.macromedia.com%2Fnetlanski%2Ffiles%2FMovie%2Fmudball.dcr 
<000000BD< HTTP/1.1  
<000000C7< Referer: http://poppy.macromedia.com/netlanski/files/Movie/mudba
<00000107< lldcrDoc.html  
<00000116< Cookie: macromedia_member_id=42339042,fad8619ee711623aea15150a53
<00000156< 2dbe77; auto_login=1; vid=80c23ef8.22181.3a557fa3.17841; 
<0000018F< net6_warning=1; flash5up_total=3  
<000001B1< Host: www.shockwave.com  
<000001CA< User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.8.1+) 
<00000208< Gecko/20010419 Netscape6/6.5b0  
<00000228< Accept: */*  
<00000235< Accept-Language: en  
<0000024A< Accept-Encoding: gzip,deflate,compress,identity  
<0000027B< Accept-Charset: ISO-8859-1, utf-8; q=0.667, *; q=0.667  
<000002B3< Keep-Alive: 300  
<000002C4< Connection: keep-alive  
<000002DC<   

Receive 351 bytes.
>00000000> HTTP/1.1 302 Moved Temporarily  
>00000020> Server: Netscape-Enterprise/4.1  
>00000041> Date: Thu, 19 Apr 2001 22:02:04 GMT  
>00000066> Location: http://www.shockwave.com/bin/shockwave/account/welcome
>000000A6> /welcome.jsp?first=sdfafs&last=safsaf&email=asffs%40safas.com&pr
>000000E6> ef=y&lang=en&age=0&url=http%3A%2F%2Fpoppy.macromedia.com%2Fnetla
>00000126> nski%2Ffiles%2FMovie%2Fmudball.dcr  
>0000014A> Connection: close  
>0000015D>
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Blocks: 35916
marking this VERIFIED again..
Status: RESOLVED → VERIFIED
QA Contact: tever → shrir
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.