Closed Bug 57012 Opened 25 years ago Closed 24 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: 25 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: 25 years ago → 24 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.