eXtropia: the open web technology company
Technology | Support | Tutorials | Development | About Us | Users | Contact Us
Development resources
 ::   WebWare 2.1 (Perl)
 ::   WebWare 2.0 (Java)
 ::   Cool hacks
radical hacks
WebStore Bug Found and Fixed for Older Browsers  
sent in this very interesting note about how WebStore can generate subtle errors in older browsers.

It's not really a problem with the Web Store but rather it's a limitation of old browsers. It seems that Internet Explorer 3.0 (the one I had problems with) has a limitation to the length of the 'NAME=' attribute of an INPUT FORM tag. This limit seems to be 128 characters (2^7); for IE3.0.

Let me back up and explain where the problem originated. Some users with old browsers (IE3.0 to be exact) were experiencing strange prices of $101 and $102 for their items! I think it actually lost us a sale or two! Those values, 101 and 102, just happend to be the shopping cart 'unique_cart_line_id' numbers (101 for the first item in the cart, 102 for the second item in the cart and so on...).

So, why were they getting mixed up with the price? Here's the first example item.

Kids Camo - Item # 6805:

The kids camo pants when displayed as a product page (db generated page) has a INPUT FORM field which has a very large NAME attribute to it:

<INPUT TYPE="hidden" NAME="item-6805|clothingkidswood|19.95|Kids Camo Pant Woodland|~lt~IMG SRC=~qq~/Html/Images/Data/kidwood.jpg~qq~ ALT=~qq~Kids Camo Woodland~qq~ vspace=~qq~5~qq~~gt~|2" VALUE="1">

You can see the NAME="" is many characters long (164 characters long to be exact). This NAME="" is defined using the @sc_db_index_for_defining_item_id which is found in the setup file. I added the weight field as the measured field to be used in the UPS calculations (more on those hacks another day).

@sc_db_index_for_defining_item_id =
  ($db{"product_id"},
   $db{"product"},
   $db{"price"},
   $db{"name"},
   $db{"image_url"},
   $db{"weight"});

The first thing I noticed about this array is that the "weight" is the last index and that the shopping cart information seems to be loosing the weight! So I thought, maybe the NAME="" is too long for 'old' web browsers and the information is getting truncated and lost when it is submitted?

Now lets take the Rokk Pack, another example:

<INPUT TYPE="hidden" NAME="item-255|packsinternalrokk|66.55|Flat Iron|~lt~IMG SRC=~qq~/Html/Images/Data/rokkflatironthmb.gif~qq~ vspace=~qq~5~qq~~gt~|5" VALUE="1">

Notice that the IMG tag information is much shorter which makes the NAME="" much shorter than the kids camo NAME="" above. The old IE3.0 browser didn't have any problems with this item, which makes sense --- it's NAME="" is only 125 characters long.

The conclusion I'm coming to is that the information after character 128 (possibly 2^7) is getting truncated and lost. This would mean that the "weight" of the item ordered would also get lost --- or to be more specific, the weight would never be written into the user's shopping cart "file" (User_carts dir.)

Here's the contents of an example shopping cart file, showing the error. Notice the truncation of the "image_url" field and the loss of the "weight" field.

1|6805|clothingkidswood|19.95|Kids Camo Pant Woodland|<IMG SRC="/Html/Images/Data/kidwood.jpg" ALT="Kids Camo |2-4 0.00|19.95|101

Notice that the ALT="Kids Camo has been truncated and the "options|price_after_options|unique_cart_line_id" fields have been added afterwards. We have lost the weight field!

$cart{"quantity"}            = 0;
$cart{"product_id"}          = 1;
$cart{"product"}             = 2;
$cart{"price"}               = 3;
$cart{"name"}                = 4;
$cart{"image_url"}           = 5;
$cart{"weight"}              = 6;
$cart{"options"}             = 7;
$cart{"price_after_options"} = 8;
$cart{"unique_cart_line_id"} = 9;

So, based on the shopping cart field definitions above: the weight field becomes the options the options field becomes the price_after_options and the price_after_options becomes the unique_cart_line_id (Doh, doh!!!!) which would explain why some people with old IE3.0 browsers were getting prices of 101 and 102 (the unique_cart_line_id numbers).

There are several ways to approach a fix for this bug. If you do not need to use the "image_url" information in the shopping cart, the fix is very simple! Do not pass the Image information to and from the shopping cart!

For the outdoorstoreusa.com, we don't display the images in the shopping cart because they are often too big (Width and Height). So we don't need to include the "image_url" in the @sc_db_index_for_defining_item_id or in Cart Definition Variables.

So now:

@sc_db_index_for_defining_item_id =
  ($db{"product_id"},
   $db{"product"},
   $db{"price"},
   $db{"name"},
   $db{"weight"});

and the Cart Definitions are:

$cart{"quantity"}            = 0;
$cart{"product_id"}          = 1;
$cart{"product"}             = 2;
$cart{"price"}               = 3;
$cart{"name"}                = 4;
$cart{"weight"}              = 5;
$cart{"options"}             = 6;
$cart{"price_after_options"} = 7;
$cart{"unique_cart_line_id"} = 8;

This produces a much smaller hidden form field for each item. For our kids camo example:

<INPUT TYPE="hidden" NAME="item-6805|clothingkidswood|19.95|Kids Camo Pant Woodland|2" VALUE="1">

Notice that the NAME attribute is much smaller now.

If you must use the "image_url" in your shopping cart try to keep it's character length as small as possible (under 128)! Don't use attributes such as ATL="", WIDTH="", HEIGHT="", VSPACE="", HSPACE="" or any others.

Let's face it, not everyone shopping on the Internet uses the latest and greatest browsers.

Visit the Outdoor Store USA.com at www.outdoorstoreusa.com for a working example of the Web Store.