Google Checkout "Edit Cart" link problem with FRAMES

[GoogleCodeExporter]

I don't have an obvious way to get this to the Google Checkout team. They don't 
seem to have a Google Code site like this. Can someone please get this bug 
report over to them. This is a serious problem for the way that webstores get 
reloaded if you aren't signed into Google and try to use the "Edit Cart" link 
to get back to the webstore that posted the cart ... it only loads into the TOP 
frame of the browser, leaving the Google "create account" and "sign in" frame 
on the screen below. They shouldn't be using frames like this.

What steps will reproduce the problem?
1. Go to any Google Checkout-enabled webstore
2. Click to checkout with Google Checkout but do not be signed in with Google
3. The shopping cart opens in Google Checkout with the cart items in the top 
frame and a "Create a Google Account to continue" or "Sign in with your Google 
Account" loaded into a frame below.
4. When you click the "Edit Cart" button to go back to the webstore that 
generated the cart, it only opens that webstore in the top frame ... cutting 
off their website severely ... and leaving the Google "create account" or "sign 
in" in the bottom frame. See the attached screenshot.

What is the expected output? What do you see instead?

Of course, we expect that you would load the entire page into one frame. When 
the person clicks to edit their cart, the "Edit Cart" Url will trigger a total 
replacement of the Google Checkout content with the webstore content. You 
shouldn't be using frames for this part of Google Checkout.

What version of the product are you using? On what operating system?

This is the behavior in all versions.

Original issue reported on code.google.com by lglath...@gmail.com on 12 Apr 2012 at 1:13

Attachments:

• badframes.jpg

[GoogleCodeExporter]

I''m having the same issue on http://crafts.hopmart.pl/index/pl/. Please fix 
this issue. Or give workaround.

Original comment by much...@gmail.com on 14 Jul 2012 at 6:54

[GoogleCodeExporter]

The workaround is to include this JS code on your checkout page ... the one 
that the user returns to if they click the 'Edit Cart' button in the Google 
Checkout UI:

        <script type="text/javascript">
            if (top.location != self.location) {
                top.location = self.location.href
            }
        </script>

Original comment by lglath...@gmail.com on 14 Jul 2012 at 7:03

[GoogleCodeExporter]

Thanks for the fix.

Original comment by joseph.f...@gmail.com on 3 Aug 2012 at 2:58

• Changed state: Invalid

[GoogleCodeExporter]

But that's a hack, isn't it? Can you setup the Edit Cart button to dissolve the 
frames and reload the merchant page in a single browser window/frame?

Original comment by lglath...@gmail.com on 3 Aug 2012 at 3:11

[GoogleCodeExporter]

I would end up putting in the same "hack" which may cause side effects in 
existing applications that are not in frames.

Original comment by joseph.f...@gmail.com on 8 Aug 2012 at 2:08

[GoogleCodeExporter]

I see ... ok ... that's fine. I'm just glad we have a way to deal with this, 
because it was a poor result to have the page load only into the top frame.

Original comment by lglath...@gmail.com on 8 Aug 2012 at 2:13

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Actually there is couple issues with proposed solution:
1. Cannot access top.location properties (security restrictions)
   This prevents me from removing the frames only for google checkout
   and not for In Page Google Analytics
2. There is visible delay before my website is removed from the frames.
   So it is being displayed inside the frame (terrible idea)
   And then it flickers and is being showed in full (bad user experience)

Please just dissolve the frames when user clicks Edit Cart.

Original comment by much...@gmail.com on 4 Sep 2012 at 1:27

[GoogleCodeExporter]

Google has made it utterly clear that this is a "will not fix" issue (at least 
for the time being). If the workaround won't work for you, then you're out of 
luck. I agree with you: The use of frames like this provides a horrible user 
experience. I'm just glad that the workaround works (well ... for me anyway).

Original comment by lglath...@gmail.com on 4 Sep 2012 at 1:57

[GoogleCodeExporter]

Up until now I have been blissfully unaware that Google are doing this. We 
completed our cart integration some time ago and this was NOT how it worked 
then! And I can't believe - cannot believe - how utterly dreadful and naff this 
is. Frames! Not only is the required fix a piece of cowboy, amateurish JS 
rubbish (for the "edit order" response), but the appearance in the browser 
looks like something from the nineties. Horrible. I wish we had never bothered 
with Checkout integration for our shopping cart system. Unfortunately we have 
some poor customers using it for their carts, so I suppose we'll have to 
persevere (for now).

More the fool us I suppose. When Iglath writes "I don't have an obvious way to 
get this to the Google Checkout team" the alarm bells should be ringing. We 
seem to be dealing with some nerds fooling around on the Olympian heights and 
somewhat removed from the real, commercial world.

What's happening to the Google I once knew and loved?

Original comment by smallgre...@gmail.com on 13 Nov 2012 at 11:51

[GoogleCodeExporter]

And let me add that this isn't the only thing wrong with this team: I've been 
screaming for them to add the merchant private data for subscription orders to 
be sent back to us on the recurring subscription notifications. A simple, 
obvious need ... that is missing ... and listed as a bug/issue for over a year!

The recurring orders have a new order id and no indication of the original 
order id. How in the heck are we supposed to match the recurring subscription 
orders with the original order to pull any dB data on our side if they won't at 
least give us back the merchant private data. Yep! You guess it: Another 
workaround is required. You have to embed the data at the item level merchant 
private data. Google Checkout Team Goobers: FIX YOUR BUGGY, FEATURE-WEAK 
SYSTEM! (see ... I told you I was screaming at them.)

Basically as far as I can tell, any simple, logical bug or issue request will 
fall into the Google Checkout Team Black Hole. Not only do they not fix the 
issue, they don't even bother to respond for months or years! As far as I can 
tell from their lack of responsiveness, the entire team is run by a very 
incompetent manager there.

There is one good guy down at Google on the commerce side, Danny Hermes, who 
works with Google Shopping (a system we had to drop because Google started 
charging for it). Other than Danny, I've been very frustrated by the devs at 
Google. They have little interest in supporting their eCommerce platform as far 
as I can tell. I'll still use it because they did roll in a lot of great 
features, but I'm not happy with the team's responsiveness to my needs. The dev 
support sucks!

Original comment by lglath...@gmail.com on 13 Nov 2012 at 5:51