One more thing: the new cart does not support "unofficial hacks" such as EJEJC_multiAdd();, EJEJC_show();, EJEJC_cartsize();, and EJEJC_cartamt();. If you're using any of those (you almost certainly aren't if you're not sure), you'll need to stick with the classic cart for now, but we should now have support for EJEJC_multiAdd(); implemented in the new cart soon.

In case you're wondering, EJEJC_show(); was a way to reuse the classic cart's "lightbox" overlay to display other things, and EJEJC_cartsize(); and EJEJC_cartamt(); could be used to assemble layout for a "minicart" in your page, though that was always a bit clumsy, so we're working on a better approach for that sort of thing with the new cart.

Just a reminder: to get the cart overlay to appear "inside" your site, make sure every sales page has at least one complete copy of your full View Cart code cart button Script code, copied directly from your Seller Admin. This should already be the case if our classic cart was displaying as an overlay even before you opt-in to try our new cart.

You only need one copy of the full View Cart code cart Script code per entire sales page, and this code is unique to you but the same for all your products, so it doesn't matter which product's button codes screen you copy it from. This code adds some javascript to your page that manages the overlay-style cart display for both our classic cart and new cart. If the overlay-style cart cannot work for any reason in a given page, the Cart buttons on that page should still work in "fallback" mode by displaying the cart in a popup window/tab.

We also just discovered and fixed an issue that may have caused that "fallback" behavior for some older versions of our button code, so if you tried our new cart and found they were opening the cart in a new window/tab, please try it again now:
http://www.e-junkie.com/ej/insider/4

I see we've already been working with you on this via email, so we'll just continue the discussion there. So far, we've seen a couple other cases like yours reported; the problem appears to be a conflict between our box.js cart-overlay script and some other javascript that affected sellers are loading into their site, which causes our script to stall out or display an error.

Anyone affected by this can try a workaround first: simply replace box.js with box_fb_n.js in your View Cart code -- or, if you have NOT opted in to join our new cart beta and are still using our classic cart, use box_fb_o.js instead. This will bypass the new routine in box.js that detects which version of the cart your account is using, and respectively just loads only the new or old cart overlay code directly; that new version autodetect routine appears to be the source of the few conflicts we've had reported to us.

E.g., here's what this View Cart workaround code would look like if you are experiencing this stalling problem and have opted-in to use our new cart (note the XXXXXX part would be unique to you, as provided in Seller Admin):

<a href="https://www.e-junkie.com/ecom/gb.php?c=cart&ejc=2&cl=XXXXXX" target="ejejc" class="ec_ejc_thkbx" onclick="return EJEJC_lc(this);"><img src="https://www.e-junkie.com/ej/ejview_cart.gif" border="0" alt="View Cart"></a>
<script type="text/javascript">
function EJEJC_lc(th) { return false; };
</script>
<script src="https://www.e-junkie.com/ecom/boxfb_n.js" type="text/javascript"></script>

That workaround will NOT be needed if your site is not stalling out or displaying a script error on load, nor will it be necessary once we sort out the reason for any conflicts that cause the stall/error.

There is no need to use box_fb_n.js if your cart buttons are working, and if your sales pages are loading without stalling out completely or showing a script error message. That would only be used to work around a rare stalling issue caused by a conflict with some other javascript an affected seller may be using in their page.

Loading speed should improve once our new cart leaves the beta testing phase, at which time we can streamline our cart code for more efficient processing; aside from that, cart loading speed depends largely on other factors that vary over time, such as the degree of demand load on our system and any network congestion issues between the buyer's ISP and the Amazon datacenter where our services are hosted.

Thanks for your suggestion; I'll pass that along to Development. Buyers can simply use the standard back-arrow icon on their device to dismiss the cart and continue shopping, but perhaps we could supplement that with with some sort of return button/icon/link in the cart itself.

At this point we don't have a firm deadline for beta testing to end; it's more of a judgment call once Dev irons out any outstanding issues found or reported, and finds no new issues or reports thereof coming in. Tentatively at this point, it seems like that should take only a month or two.

Thanks for your feedback. We got a couple other reports like yours in the span of about half an hour but were unable to reproduce any problem by the time they arrived. Dev is investigating now, but we think it was just a general transient issue such as a network connectivity/routing glitch at that moment, which would have affected the old cart as well. Please feel free to opt-in again and test it for yourself now.



As you say, it does appear the new cart scrolls to the top of the page when it renders, so I'll ask Dev if there's any way they could change the rendering approach to preserve the page scroll position on cart view.

We are probably going to add a Close or Continue/Resume Shopping widget of some sort in the fallback/mobile cart, since that's been popularly requested. The overlay-style cart may not need one, as there's an X icon to close the cart overlay there, which users should already be familiar with from similar "lightbox" style overlays.



Our demo cart buttons for the Braintree payment gateway are currently enabled to use the new cart beta:

25http://www.e-junkie.com/ej/braintree-shopping-cart.htm25