View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005204||Taler||other||public||2017-12-09 02:58||2019-12-20 19:11|
|Reporter||Florian Dold||Assigned To||Marcello Stanisci|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Product Version||git (master)|
|Target Version||0.6||Fixed in Version||0.6|
|Summary||0005204: experiment with opening wallet page in new tab to avoid white pages and flickering|
|Description||The 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
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.
|Tags||No tags attached.|
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.
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
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).
||LONG time fixed.|
|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|