Excessive Honesty Disclaimer: This looks like a big long bug list, and one that makes it look like our system has more than its share of problems. I suspect the real story is that most sites with shopping systems have just as many bugs lurking -- they just don't admit it. Furthermore, most of these problems are going to crop up very rarely, if at all. Even so, rather than have our customers getting frustrated by problems we know about, I decided to list all the known issues here, along with the work-arounds we have devised. The other point is that a number of the bugs listed below are bugs (or "undocumented features") of one or another of the web browsers you might use to visit our site. If the web browser has a bug, even a properly coded page can make the browser misbehave. Such problems are in large part beyond our control, but at least we can report them, and list the appropriate known work-arounds for each problem. Better that than having our customers wasting their time getting frustrated. I have gone into a lot of detail explaining the bugs, and that also makes the list look pretty long.
In the interests of solving the most problems fastest. the bugs are listed in the order of their likelihood of occuring, not in order of severity. That in fact works out to being more or less from least to most severe, which is probably a good sign. If you spot a bug that's not listed, let us know at firstname.lastname@example.org.
Roger MacBride Allen, Publisher
Problem: In the non-frames version of the FoxAcre Catalog, all the navigation elements vanish.
This is a purely cosmetic problem, which we seem to have solved -- but it still might crop up under some unexpected set of circumstances, so we'll leave the fix posted here.
The frames and non-frames versions of the catalog pages are generated from the same source code. When that code is loaded, a flag variable is supposed to be set according to whether frames are or are not in use, and that flag is used to turn on and off the display of various elements of the pages. Sometimes the flag gets confused, or the page does not read it.
Solution: If you are reading this in a pop-up window, finish reading these instructions and then close the pop-window. Use the link on the front page of the Catalog Welcome Page to open this buglist page page full-screen. Then, click here and you'll be returned to the front page of the non-frames version of the FoxAcre Welcome Catalog with all navigation elements in place. You might want to set a bookmark on the Catalog Welcome Page so you can return to it easily. Also note there are hyperlinks at the bottom of the catalog main page which do the same job of resetting from this error or the one below.
Problem: Navigation Tables and other elements from the non-frames version of the FoxAcre Catalog appear while using the frames version.
This is the flip-side of the above-described problem. To get the unwanted text out of the way, just select the "FoxAcre Press Welcome Page" choice from the left-hand frame, then return to whatever page you were viewing, Alternately, use the links at the bottom of the Catalog Welcome Page. Either link should force a reset of the flag and get the pages back to normal.
Problem: A customer visits our Wholesale store, and then later our Retail store (or vice versa). Customer orders one or more item, then selects checkout, and sees the "Still Looking" page, which report that the user has not selected any items.
Related Problem: A customer is able to use one browser to complete an order, but is unable to use another browser on the same computer to complete an order. Customer experiences the behavior described above, which make it appear that a given browser doesn't "work" with our catalog.
Here's what's going on: Our shopping software attaches a client-number to each new visitor to our catalog. Once you complete an order, this client number is erased. On the next visit, you'll start over with a new number. However, if you leave our shopping system without completing an order, and then return later, the shopping system checks whatever cookies are stored by your browser, and/or your web address and the type of browser you are using, to match you up with your previous client-number, which is in turn attached to data on the status of your order at the time you last visited the site. This allows the system remembers what books you have already ordered, and your address information if you have already entered it. (This information is held securely, and we do not share customer information with anyone. Also note credit card numbers are not retained or stored by our system.) Because client-number tracking is in part browser-based, if you use four different browsers at one computer, you'll get four different client numbers.
Under certain rare and complicated circumstances, if you visit our wholesale store, start an order and abandon it and, using the same browser and computer, then start again in our retail store, (or vice versa) you can wind up with a browser linked to two client numbers, one in our non-secure server, and one in our secure server. For example, if you go to, say, the retail theme and get as far as retail checkout (which is accessed via the secure server), and then empty your shopping cart, you have left a client number linked to an empty shopping cart behind. If you then go into the wholesale store and order some items you will start a new client number, which is the one that will know about your order. If you them try to go to wholesale checkout, our shopping system might match you up with your first client number, and then pull up the empty shopping cart left behind in the retail store. Thus, the system wouldn't let you check out because it would think you hadn't ordered anything. This would only effect whatever browser (ie, Netscape, Explorer, etc.) you used for visits to both stores.
We've done our best to code the system so as to prevent this snarl-up from happening to you, but if it does occur, the best thing to do is start over by zapping both your non-secure and secure client numbers, and then starting fresh. You can do this by using the links below. The links will each bring you to a page that says you have been forgotten. One will zap any identity in the normal side of the server, and the other will zap you client number on the secure server. Use both of them, one after the other. Hit the browser's "back" button to return to this page once you are forgotten. Once you have been forgotten twice, restart your order.
Secure-server amnesia inducer.
Non-secure server amnesia inducer.
Just incidentally, if you are feeling paranoid about privacy, you can use these links at any time to blot out any record of your visit to our site. (You'll also have to erase the cookies on your own computer, just to be on the safe side.)
Because our shopping system assigns a different client number based in part on what browser you use, this problem can look like a browser bug. For example, it might seem as if Explorer didn't "work" with our system, but that Mozilla did, or else that Explorer did work, but maybe Opera did not. We have tested the site with the Windows version of Opera 7.11, Mozilla 1 to 1.3, Explorer 5 and 6, and Netscape 4.x to 7, plus OS/2 versions of Netscape and Opera. They all work. The only true browser-based incompatibility we have found is discussed here. See also the Microsoft Explorer 6 issue, and see if you think that counts as an incompatibility.
Problem: Customer using Microsoft Explorer 6 has item(s) in shopping basket, selects checkout and sees "Still Looking" page, which report that the user has not selected any items.
Note: this error closely resembles the error above. The above error is more likely. Try using the fix for it first.
We have set up our order-taking system in a way that should bypass this problem altogether, by using an alternate and very secure means to retain the same information. However, it's possible that we missed a fix, and, under certain circumstances, this problem could crop up.
Problem: Customer using Netscape 4.x browser selects PayPal as payment method at checkout. After completing the order, customer proceeds to the PayPal Payment Page, clicks on one of the "Pay via PayPal" buttons -- and the customer's browser crashes.
We don't know why, but this bug seems to have gone away as mysteriously as it arrived. All the PayPal payment buttons always worked just fine in Netscape 7.01, Explorer 4 and up, and in Mozilla and Opera. However, for a while there, older versions of Netscape crashed. The crash actually took place after the browser had left FoxAcre and was communicating with PayPal, but before the screen refreshed to the PayPal welcome page. It would seem that there is a bug in Netscape 4.x (i.e., versions 4.1. 4.2, 4.6 etc.), and that it crashed when talking to Paypal. However, it stopped happening, presumably because Paypal came up with a way to avoid the problem from their end. The problem seems solved, but it might pop up again. Just to be on the safe side, if you use Netscape 4.x, we strongly suggest you use another browser to place an order and pay for it with PayPal.
Catalog Front Non-Frames Version
Catalog Front Frames Version
To avoid confusing yourself, don't use these links
if you are viewing
this page inside a pop-up window. Instead, close the pop-up window
and use the Catalog's navigation links.