View Issue Details

IDProjectCategoryView StatusLast Update
0005204Talerotherpublic2019-12-20 19:11
ReporterFlorian Dold Assigned ToMarcello Stanisci  
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.6Fixed in Version0.6 
Summary0005204: experiment with opening wallet page in new tab to avoid white pages and flickering
DescriptionThe merchant can then simply show a page with

"Waiting for payment to be processed with GNU Taler. If no wallet page page appeared yet, click HERE."

The "click HERE" link should never be necessary, but is useful for users who accidentally close the wallet page, end up back on the merchant page and don't know how to refresh pages.

We also need to track if the user closed the original page, so we can navigate there if necessary after the payment is done.

This has some significant advantages:
1) no flickering or reloading that is noticeable by the user
2) if using JavaScript payments in a stateful app (such as a game), we can pay without destroying the application state
3) it's forward-compatible with the W3C payment request API, where the wallet would be displayed in a browser-secured overlay that the merchant page can't tamper with.

Also from my experience it seems like other payment methods are already doing this, so it's not new or unexpected for users.
TagsNo tags attached.


Christian Grothoff

2017-12-09 10:30

manager   ~0012639

I don't really like the idea. If we want to minimize the flickering, maybe we can simply change the 402 body that is being returned instead? From setting it to invisible initially (would the Wallet CSS magic for that?) to simply artificially delaying the transmission of the body by 100ms, I see quite a few options.

Tabs are IMO bad as they ought to imply a context switch. Some users have hundreds of tabs open, and they may no longer be able to associate the payment tab with the original page. It also destroys the ability to navigate 'back'.

Finally, if (3) actually happens and works nicely, then the whole tab business is just a distraction, as in that case I suspect we might just implement (3) directly without the tab-method as an intermediate option, and we get (2) solved that way as well. But: it might be OK to have the tab as an option to address (2) today, i.e. if the merchant explicitly specifies "use tab" to avoid the state destruction issue. Still, don't see this as a priority today.

Florian Dold

2017-12-09 13:50

manager   ~0012644

The wallet is already using CSS magic to make the page blank. I've come to the conclusion that this is sometimes the worse experience though: If /pay takes a long time, the user just has to stare at a blank page. When opening the payment dialog in a new tab, we can make wait-states more friendly to the user.

We could have a less jarring 402 page though, other than blanking it out via the wallet or showing an ugly fallback credit card form for a second.

Regarding context switching: I'm one of these users with many tabs open ;-) I had this concern too at first, but then when the payment succeeds the wallet *knows* which tab triggered it, and can simply focus on that after payment, if still open.

Regarding the back button: Easily fixed using the standard history API, the wallet page creates an dummy navigation, and when the back button (or other means of back-navigation) is used then (1) the wallet page closes and (2) the merchant page is navigated back.

I don't think the merchant should decide between "new tab" and "same page". By making the merchant assume the payment happens in a new tab (or Payment Request API overlay), we can always provide the user with the best experience depending on their device or browser (on a mobile device, accepting the payment might even happen in another app and not in the browser).

(Some background: With Stripe payments, the merchant embeds some iframe from Stripe. But on mobile, Stripe always opens their dialog in a new tab and refuses to show the iframe, since many merchants have really bad mobile sites. So it can make sense to take choice away from the merchant for better UX.)

So in conclusion, I would not make it a priority to play around with this now, but we should
1) improve the 402 page
2) make sure the merchant frontends can also deal with the payment happening in a new tab (without doing anything weird, like timeouts that indicate a missing extension)
3) eventually think about payments without changing the state (via JS) when necessary, but now now

Florian Dold

2017-12-09 16:31

manager   ~0012647

I've made the 402 page less jarring, and disabled the page blanking in the wallet. It actually looks pretty okay now, but we need to come back to this to support asynchronous payments (that don't destroy web app state).

Marcello Stanisci

2019-06-24 11:18

viewer   ~0014572

LONG time fixed.

Issue History

Date Modified Username Field Change
2017-12-09 02:58 Florian Dold New Issue
2017-12-09 03:01 Florian Dold Description Updated
2017-12-09 10:25 Christian Grothoff Severity minor => feature
2017-12-09 10:25 Christian Grothoff Status new => feedback
2017-12-09 10:25 Christian Grothoff Product Version => git (master)
2017-12-09 10:30 Christian Grothoff Note Added: 0012639
2017-12-09 13:50 Florian Dold Note Added: 0012644
2017-12-09 13:50 Florian Dold Status feedback => new
2017-12-09 16:31 Florian Dold Note Added: 0012647
2019-06-24 11:18 Marcello Stanisci Assigned To => Marcello Stanisci
2019-06-24 11:18 Marcello Stanisci Status new => resolved
2019-06-24 11:18 Marcello Stanisci Resolution open => fixed
2019-06-24 11:18 Marcello Stanisci Note Added: 0014572
2019-09-16 09:19 Christian Grothoff Fixed in Version => 0.6
2019-09-16 09:19 Christian Grothoff Target Version => 0.6
2019-12-20 19:11 Christian Grothoff Status resolved => closed