Fernando Jiménez Moreno [:ferjm] Assignee
	Description • 12 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=830358#c14

We are currenlty matching the trusted UI dialogs opened via mozPay or mozId with the identifier of the mozChromeEvent that triggers the creation of each dialog. This might work with dialogs hosting independent flows for payment and identity, but would not work with two or more different dialogs hosting different payment flows as we always keep the latest mozChromeEvent id [1] that triggered the creation of the dialog hosting the payment flow.

We need to match each dialog with the DOMRequest identifier that triggered its creation.

[1] http://mxr.mozilla.org/gaia/source/apps/system/js/payment.js#98

	Fernando Jiménez Moreno [:ferjm] Assignee
	Comment 1 • 12 years ago

Requesting tef+ since this bug track the same issue that we tried to fix at Bug 828182

	Fernando Jiménez Moreno [:ferjm] Assignee
	Comment 2 • 12 years ago

One good reason to block here is that we won't be able open two payment or identity flows one after the other from the same app, as the second one would appear on top of the app instead of on top of the homescreen.

	Fernando Jiménez Moreno [:ferjm] Assignee
	Comment 3 • 12 years ago

Pointer to Github pull-request

	Fernando Jiménez Moreno [:ferjm] Assignee
	Comment 4 • 12 years ago

Comment on attachment 704966 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7737

I've done several testing with both flows, identity and payments, but I would appreciate if you could also test it. Thanks Jed!

	Jed Parsons (use needinfo, please) [:jedp, :jparsons]
	Comment 5 • 12 years ago

Comment on attachment 704966 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7737

Tested identity flow, including two separate apps requesting identities concurrently, and it works great.  r=me

Once Bug 832948 and Bug 833392 land, this is good to go.

Thanks, Fernando!

	Jason Smith [:jsmith]
	Comment 6 • 12 years ago

Triage is a bit puzzled on this one. Can this actually reproduce with our v1 requirements? We only have one payment flow for v1.

How would I reproduce this with our existing v1 constraints? Can you explain a bit more?

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 7 • 12 years ago

Fernando: It's unclear what the effect is of not fixing this bug.

Can you describe exact UI experience a user sees due to this bug?

	Fernando Jiménez Moreno [:ferjm] Assignee
	Comment 8 • 12 years ago

(In reply to Jason Smith [:jsmith] from comment #6)
> Triage is a bit puzzled on this one. 
Sorry about the lack of info, it is quite spread between different bugs. 

> Can this actually reproduce with our v1
> requirements? We only have one payment flow for v1.
> 

Correct me if I am wrong, but even if we only have one payment flow the requirements were that we should support multiple trusted UIs (hosting payment or identity flows). The fact that we have only one payment provider doesn't mean that we cannot have two different apps with two different instances of the payment flow opened in parallel. This fact is also extensible to the identity flow. In any case, the bug was not only affecting parallel payment/identity flows but, at least, also consecutive payment flows. Without this fix, a second payment flow opened from the same application is opened on top of the application instead of on top of the homescreen if a previous application had a trusted dialog associated even if this has already being closed, which is a pretty confusing UX.

> How would I reproduce this with our existing v1 constraints? Can you explain
> a bit more?

Clear STR can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=830358#c11 (note that you will need to have the payment provider data mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=830358#c8)


(In reply to Jonas Sicking (:sicking) from comment #7)
> Fernando: It's unclear what the effect is of not fixing this bug.
> 
> Can you describe exact UI experience a user sees due to this bug?

When the issue appears, the trusted UI is shown on top of the app instead of on top of the homescreen, which throws away the whole point of the trusted UI and exposes a confusing UX. Also, the embedded content (at least for the payment flow) does not work as expected when this issue appears as clicking in the 'Pay' or 'Cancel' buttons trigger the callbacks that are injected in the payment flow letting the requester app know that the flow is finished but the trusted UI is not closed until the second click.

	Dylan Oliver [:doliver]
	Comment 9 • 12 years ago

Looks like this has been merged -- can this issue be resolved?

	amiller
	Comment 10 • 11 years ago

Does not make sense to create a regression issue.

	Darren
	Comment 11 • 11 years ago

Cannot verify, need steps to blackbox test this issue.