Back from view cart empties cart

[RohanM]

Description

When shopping as a guest, my cart get emptied if I hit the "backward" browser button.

Expected Behavior

If I am logged in, or if I am shopping as a guest, if I put products in my cart and go to the basket page, when hitting the browser "backward" button, my cart should remain with the products I put in it, and I should just be sent back to the shopfront page.

Actual Behavior

When I shop as a guest, I add products and then go to cart page, if I hit the browser "backward" button, I'm sent back to shopfront page BUT my cart is emptied.

Steps to Reproduce

1. Do not log in, and open any shopfront. Add products to your cart and click on "view cart" button (either from bottom of product lists, or small right corner "cart" button)
2. When on cart page, hit the browser "backward" button and see what happens.

Animated Gif/Screenshot

https://www.useloom.com/share/1e4de54bbbf04944ac8147e2d15232ce

Context

Reported originally from Rohan when testing previous spree upgrade, re-tested and updated by Myriam.

Severity

S2, all guest users are affected, and placing order is a big feature, and pretty big UX impact that has no really workaround?

Your Environment

• Version used: 1.10.1
• Browser name and version: Version 64.0.3282.167 (Official Build) (64-bit)
• Operating System and version (desktop or mobile): Ubuntu 16.04 LTS

Possible Fix

?

[stveep]

So I was able to reproduce this a few times, on chrome, via both "edit cart" buttons. However now (with no changes to the code) it seems to work fine...I've cleared cookies, disabled cache and still ok. Even when I try on other browsers (Firefox, Safari) it is working ok.

I've also attempted to reproduce this in a feature test - but again, this works ok:
stveep@644bd7b

I'm not that familiar with how the cart is persisted so just thought I'd check weather anyone else has ideas before I dig into it. I planned to see if the clear function was being called as I went through the navigation above (there are various points where this can happen, such as changing OC) - but obviously not being able to reproduce it is not helping with this.

On the gif above, the login screen also pops up after pressing back - this doesn't happen for me.

[sauloperez]

Perhaps you @myriamboure can reproduce it again?

[myriamboure]

I reproduced again https://www.useloom.com/share/ab9547267f3f48b99612325bd54ca4b7 and interestingly I tried that time both as logged in (first) and then logged out. You will see in both cases it goes back to the cart status that was previously. When logged in I had 2 items in my cart from before, add 2, goes to cart, then hit "previous page" button and you will see the cart is back to 2. I can't help more on the tech side but seems easy to reproduce, don't understand why you can't @stveep ...

[stveep]

Hah ok I think I have a start on this. In Chrome I now get the bug. In Firefox (v 59.0.1) though, everything seems to work ok. In Chrome, the bug goes away if I open the javascript console (this was obviously why I couldn't reproduce when investigating further!). I had caching disabled when using dev tools - if I turn caching back on, the bug reappears. So I guess it probably reloads a cached version of the shop page or something. Any easy suggestions from anyone about how to stop that? Otherwise I will investigate more...

It's hard to debug bugs that don't happen when you use the console 😆

[sauloperez]

Does refreshing the page fix the problem? do you see the items in your cart then? honestly, I don't think we can do anything here, as long as this is just a cached version.

[myriamboure]

If I click on backward and refresh the page it doesn't change anything items are still lost and not anymore in cart.

[sauloperez]

what if you perform a "hard" refresh pressing Ctrl + Shift + R? we need to clarify if this is just browser cache or something else.

[myriamboure]

I tried this and no change, products still don't reappear in the cart...

[myriamboure]

Any progress on this @stveep ? We said it's s2 bug so we are want to solve it quickly... if the problem is deeper we can rediscuss but we need to agee on a path to achieve the user experience we want to offer (cart should remain if you hit backward button).

[daniellemoorhead]

@stveep

If life got too crazy and there's no time at the moment then let's unassign you for now and then you can pick it (or something else) up when you are back online. OK?

[stveep]

I am a bit out of my comfort zone with this but after a bit of shameless Googling have implemented this solution to force the page to refresh:

https://jacopretorius.net/2014/01/force-page-to-reload-on-browser-back-in-rails.html

This seems to have fixed it for me. It might make navigation generally feel a bit less slick as the page will reload everything each time so needs some testing. Let me know what you think about it.

A few more notes from this issue in case they are useful:

• The order is still in the database (in "cart" stage) after the back button is pressed, so it's a front end issue.
• If you go back and put more items in the cart after it gets emptied, it overwrites the original order in the database. I think this is linked to the session?
• The Angular Cart service is also emptied of the added items when the back button is pressed. Another way to fix this might be to force the angular service to re-sync with the database after back is pressed?
• This issue affects logged-in users as well as guests

[daniellemoorhead]

@mkllnk @oeoeaio @sauloperez @enricostano @Matt-Yorkley @KeirOsborn @HugsDaniel and everyone else actively helping out in the developer community, any assistance you can offer @stveep with the above (considering what has already been discussed in the PR #2268) would be most gratefully accepted.

[stveep]

Just doing a bit more investigation - this does seem to be Chrome specific. I don't get the bug in Firefox or Safari (On UK production site and in dev). Anyone know any differences in browser behaviour that could explain it?

In Chrome: Adding items and clicking edit cart results in currentOrder (injected in the script tag) with correct items (on edit cart page). Then pressing back empties the cart, and the currentOrder injection has no items [this is used to populate the Angular cart service]. Refreshing this page doesn't result in the items being in the cart, but the same order id is injected (with no items).

In Safari and Firefox: Adding items and clicking edit cart results in currentOrder (injected in the script tag) with correct items (on edit cart page). Pressing back does not empty the cart, but the resulting page has the incorrect currentOrder script (no items). Refreshing the page results in the correct currentOrder (and correct items in cart).

[myriamboure]

I just test in Firefox @stveep and I get exactly the same result as in Chrome: on French production I put items in cart and go to cart, then press the "backward" button, it empties cart. I tried on uk production as well and get the same result. @sstead has tested your fix #2268 and it seems to work, which is good! I'm not sure how to test about performance, I had a check on Aus staging and don't see that it is slowing down the process really, but maybe it does, I have nothing to compare, we need data for that I guess. How can we measure impact of this PR on performance? @sauloperez @mkllnk ? Cause if it doesn't impact performance we can just merge Steeve PR I guess as it solves the problem...

[mkllnk]

We can't measure the real impact on performance without using it in production. And the only data I have for that is response time.

I'm not sure if other instances have other tools to measure their server load.

So I think we can merge Steve's pull request and see what happens. If it's a problem, we can either revert it or do a better implementation.

[sauloperez]

I agree. We set up Skylight to monitor performance some time ago and we can watch it to spot any performance degradation.

[daniellemoorhead]

Reopen as @stveep has an alternative fix that may be better.

[myriamboure]

Ok I'm closing this as solution has been merged and alternative other solution has not been approved, the problem seems solved anyway so if we see performance issues we will open another issue.