Internet Explorer Woes, checkout will not complete.
IE9 users cannot complete the checkout process unless the order summary pane is disabled. As this disables the ability for users to see their totals, including taxes and shipping applied to the bottom line, this is not an elegant solution.
Are there any others having the same issues? I need to resolve this immediately.
Comments
We're trying to push these
We're trying to push these kinds of requests to either the Q&A of the site or submit actual bugs to the issue que for your payment gateway.
My apologies Josh. I had
My apologies Josh. I had submitted a few questions to the Q&A area and didn't receive any feedback. My assumption was the Q&A area might be for quick, FAQ type questions and this more complicated issue might live better within the discussions area -- I guess my line of thinking was a little lopsided.
This particular issue isn't relevant to the payment gateway, as the problem happens well in advance of the payment process. Whenever the Cart Summary is active, it becomes impossible to "Continue to the next step." Users aren't even making it to the checkout process.
Should I move this question there, or can a moderator do that for me?
@Threadsniper did you move
@Threadsniper did you move this over to Q&A -- we are having the same issue and looking for help to resolve.
Thank you.
I did
I did, and sorry for the late reply here. I still haven't resolved this on my end. Trying desperately to figure out where the problem lies, as I fear the lack of cart summary is detracting quite a bit from the user experience on the store and possibly losing my client some sales.
http://www.drupalcommerce.org/questions/3378/ie9-users-cannot-complete-c...
I have diagnosed this problem.I think it is a core BUG
I have identified this as happening only with certain versions of IE and only when IE (what I think Microsoft calls) "crosses a boundary." Or in other words, when the response comes BACK from a payment gateway.
If you sniff the HTTP headers between a payment acceptance and the verification page in Drupal Commerce you get the following (assuming orderID=NNN, X=module for accepting payment) IF you are NOT crossing a boundary
GET /checkout/NNN/X_payment_verification_page?....
Accept: */*\r\n
[stuff deleted]
Cookie: has js=1; SESSfoo=bar
But if you are coming back from a DIFFERENT domain (e.g. say a payment vendor) then you get
GET /checkout/NNN/X_payment_verification_page?....
Accept: */*\r\n
[stuff deleted]
Cookie: has js=1\r\n
NOTE the sudden LACK of a session passed from IE. This BREAKS drupal commerce because the way DC is written is that a user CANNOT see their own orders unless they have a session associated with it. Drupal Commerce will return a "404 Not found" error when there is no session associated with this.
Note that if you are using IE and you hit the "refresh" button it suddenly now works.
If you sniff the tcp data you find that IE will now send the session. E.g.
GET /checkout/NNN/X_payment_verification_page?....
Accept: */*\r\n
[stuff deleted]
Cookie: has js=1; SESSfoo=bar
Note: Testing with Firefox, Chrome, and Safari show they are not affected. Only IE and only when coming back from a different domain to drupal commerce for payment confirmation. (e.g. exactly what you'd normally do in working with a payment gateway). So far I've been able to get this to repeat 100% of the time with IE 9.0.8112.16421 on Windows 7 64bit.
I don't know if this is a security "feature" of IE, or if this is caused by how drupal commerce identifies incoming browsers. Solutions could
involve looking for lost IE sessions and pushing a reload (since the reload fixes the issue), moving the session variable from cookie to the GET string, or getting microsoft to fix this "feature."
But as DC exists now requiring sessions to view the final payment confirmation, this prevents IE users from actually completing an order if they are being sent "back" from a foreign domain.
Note: I am not an IE expert, but it seems like there was some discussion along these lines here http://stackoverflow.com/questions/1324181/ie8-losing-session-cookies-in... even though in the discussion they were looking at pop-up windows and here we are staying within the same window and having an IE user return from a payment gateway.
clarification
In re-reading I see I said
> how drupal commerce identifies incoming browsers
Which might be unlcear: To clarify: I was referring to the identity of the user/browser/transaction, not IE vs whatever_browser
I've done many other e-commerce solutions and in many the processing of the information for CC payments there is some orderID, transactionID, and/or hashing to track payment and session is only used for display. In Drupal Commerce, it appears the session is the underlying glue and since Dc just says "ya whatever - some module will take care of it" for payment - there doesn't appear to be a good underlying core generic transactionID API for handling CC payments. Since at the core of drupal (and thus commerce) the session is to identify what's going on and set responses, this loss of session (and thus identity) is kind of a show stopper for IE users on drupal commerce.
If you find a bug, please
If you find a bug, please post this information here:
http://drupal.org/project/issues/commerce?categories=All
Sorry I never responded above. I think we're going to need some form of "email me when someone replies" capabilities added to the site. For the Q&A, we're backlogged sometimes up to a month before we can get a response. Once a week I go through the questions that haven't received any sort of answer and attempt to give you something helpful. What is also VERY helpful is that you try to answer one question for every question you post.
Josh