URL: http://www.uburst.com/cgi-bin/dcforum/dcboard.cgi
Forum: ushop_place_order
Thread Number: 152
[ Go back to previous page ]

Original Message
"STALLS on uShopOrderButton.class IE5.5/WinME"

Posted by Gary Torello [gary@hometoyparty.com] on at 11:56 AM

uShop 3.0 has been working WONDERFULLY for months.. until NOW, I have a user using IE5.5 on WindowsME that can't get past the "click here to proceed" which invokes uShopOrderButton.class

Sh'e able to add products to the cart, can see the running total in the mini cart, clicks "Sumit Order" which loads order.html ok, then clicks the graphical button for uShopOrderButton.class - and everything just sits there! User sees the message "applet started" breifly in the status bar. nothing loads.. user never leaves this screen.

I've reviewed all of the seemingly related posts, have checked simple things like codebase settings, tables without width tags, etc.. have simplified the code of the template pages, and still no luck.

We have numerous other users successfully using this daily with both Win5.x and NS browsers. I'm suspecting perhaps WinME which I have absolutely NO knowledge of. (where would we be without MicroSatan to blame everything on hehe)

If you'd like to look at the implementation, email me seperately as I'll have to send you a valid username & PW to access it (it's an ordering system for our licenced consultants only).


Gary Torello

Table of contents

Messages in this discussion
"RE: STALLS on uShopOrderButton.class IE5.5/WinME"
Posted by Bill Weiner on at 08:46 AM
Do you happen to know if that customer had "JavaScript" enabled? That is, at that particular point....when the uShopOrderButton is pressed.... uShop utilizes "JavaScript" to transfer from the Java front-end to the CGI back-end. So if "JavaScript" was disabled on her browser, that could explain why all the applets worked fine up to that point but "stalled" when the uShopOrderButton was pressed.

Otherwise, send us the username and password at support@uburst.com and we'll take a look at it.

"RE: STALLS on uShopOrderButton.class IE5.5/WinME"
Posted by Gary Torello [gary@hometoyparty.com] on at 02:01 PM
Yes, as far as I can be sure without actually being there.. I went through the IE setup options with her one by one via telephone, and she assures me Javascript is enabled. I've also sent access info via e-mail.


Gary Torello

"RE: STALLS on uShopOrderButton.class IE5.5/WinME"
Posted by Bill Weiner on at 07:49 AM
I took a look at your site with IE 5.5 (on Win98 since I don't have access to a WinME machine at this time)... and it all seemed to work fine for me. I also looked at your HTML, directory structure and parameter settings... and that all looked fine too.

The only "strange" thing that I saw was that with IE5.5 (and not with Netscape), I got a second "username/password" screen upon following your "submit order" link. (The link that brings you to the page with the uShopOrderButton applet on it). Everything continued to work fine with IE5.5/Win98...once I entered the username/password a 2nd time.... but maybe that is related to the problem that customer was having with IE5.5/WinME? That is, maybe that customer's IE5.5/WinME browser was trying to request the username/password again once the order button applet was pressed and before the "display_cart.html" page was displayed and that is screwing something up? So maybe it's related to that second username/password request.

"RE: STALLS on uShopOrderButton.class IE5.5/WinME"
Posted by Gary Torello [gary@hometoyparty.com] on at 03:11 PM
Wow.. another twist- this is the first I've heard of the 2nd password being requested for the Username/PW type I sent you - although it IS possible I guess.. access to this area of the website is 2-teired;

Consultants and "consultants-to-be" can access the /demsupport subdir via password groups set up in .htaccess - Only actual consultants can reach the demsupport/order/html subdir as it has it's own .htaccess file which uses the SAME AuthUserFile, AuthGroupFile and AuthName which restricts access based on the "group" the username is paired with. By setting it up this way, those with FULL access can get all the way in, those with partial access get in so far, can do most things, but can't place wholesale orders yet.

The typical response to this setup is that those without FULL access see the 2nd PW request, but those who are allowed FULL access never see the 2nd. Tests out that way on our machines here running Win98, IE 5.50.4134.0600IC, also with NS and Opera.

In any event, I talked to the consultant who's having the problem ands she is NOT seeing the 2nd PW request.. she gets right thru to the screen with the order button applet on it, but then clicking on that - nothing happens! arrgghh