Closed
Bug 795023
Opened 12 years ago
Closed 12 years ago
Use the TrustedUIManager from navigator.id Gaia implementation instead of the PopupManager to trigger a trusted dialog
Categories
(Firefox OS Graveyard :: Gaia, defect, P1)
Firefox OS Graveyard
Gaia
Tracking
(blocking-basecamp:-)
RESOLVED
DUPLICATE
of bug 794680
blocking-basecamp | - |
People
(Reporter: jedp, Assigned: zaach)
References
Details
(Keywords: feature, Whiteboard: [LOE:S] [system/trusted_dialog])
In order to implement the payment and identity flows for basecamp, navigator.id needs a trusted UI.
There is already a requirement for a trusted UI for mozPay, and the consensus appears to be that, for v1 at least, it will not be possible to make a generalized trusted ui api that would be available to native services like mozPay, id, etc.
We are fine with copy-and-paste solutions. But in the end, the flows require a UI for nav.id that looks and acts exactly like the one for mozPay, and provides a way for us to message to and from the native nav.id code.
mozPay trustworthy UI: #768943
Comment 1•12 years ago
|
||
Is this a Gaia or Platform bug? It feels Gaiaish.
blocking-basecamp: --- → ?
Comment 2•12 years ago
|
||
Comment 3•12 years ago
|
||
Migrated to Gaia GitHub - https://github.com/mozilla-b2g/gaia/issues/5323, as this is a front-end feature.
Status: NEW → RESOLVED
blocking-basecamp: ? → ---
Closed: 12 years ago
Resolution: --- → INVALID
Updated•12 years ago
|
No longer blocks: basecamp-id
Comment 4•12 years ago
|
||
Keeping this bug for project tracking purposes only.
Developer details and technical requirements in github.
https://github.com/mozilla-b2g/gaia/issues/5323 (assigned to Fernando on the Gaia team)
Comment 5•12 years ago
|
||
I'd really prefer that we talk this out before you take action, as there's ways we can figure out tracking. But this is still not valid as it stands right now.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → INVALID
Comment 6•12 years ago
|
||
Okay, per talking with dietrich, all feature tracking that is v1 also needs to be in bugzilla. Moving this to Gaia in bugzilla and reopening.
Status: RESOLVED → UNCONFIRMED
Component: General → Gaia
Ever confirmed: false
Resolution: INVALID → ---
Updated•12 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•12 years ago
|
Whiteboard: [LOE:M]
Comment 7•12 years ago
|
||
My apologies for any confusion ferjm that this massive bug churn looks like. So 10/1 and after, they want any v1 tracking done in bugzilla. I'm closing the github issue, migrating the info to here, and starting tracking here.
Assignee: nobody → ferjmoreno
blocking-basecamp: --- → ?
Whiteboard: [LOE:M] → [LOE:M] [system/trusted_dialog]
Comment 8•12 years ago
|
||
This bug's scope is limited to making the existing popup UI "trusted."
Updated•12 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Summary: Implement a trusted ui for navigator.id that functions exactly like the one for mozPay → Use the TrustedUIManager from navigator.id Gaia implementation instead of the PopupManager to trigger a trusted dialog
Whiteboard: [LOE:M] [system/trusted_dialog] → [LOE:S] [system/trusted_dialog]
Updated•12 years ago
|
Comment 9•12 years ago
|
||
Fernando, how is this coming along?
Updated•12 years ago
|
blocking-basecamp: ? → +
Comment 10•12 years ago
|
||
(In reply to Lucas Adamski from comment #9)
> Fernando, how is this coming along?
No work done so far. This is blocked by Bug 794680. Once that one lands, this bug should be trivial to implement. It should only be a matter of using the TrustedUIManager instead of the PopupManager as it is currently used in https://bugzilla.mozilla.org/attachment.cgi?id=667617&action=diff#a/apps/system/js/identity.js_sec2
Comment 11•12 years ago
|
||
Fernando: I think Zach Carter on my team can handle this if you'd like, following your example on nav.pay, since he's also writing the identity Gaia tests. What do you think? Now that you've created the example, as you say it should be easy :)
Plus, this means one patch, instead of two.
Updated•12 years ago
|
Priority: -- → P1
Comment 13•12 years ago
|
||
Per today's b2g meeting - at risk features do not block ship. Renoming.
blocking-basecamp: + → ?
Comment 14•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #13)
> Per today's b2g meeting - at risk features do not block ship. Renoming.
Ignore my comment here. This was a point of confusion on my part.
Assignee | ||
Comment 16•12 years ago
|
||
PR awaiting review: https://github.com/mozilla-b2g/gaia/pull/5854
Comment 17•12 years ago
|
||
(In reply to Zachary Carter [:zaach] from comment #16)
> PR awaiting review: https://github.com/mozilla-b2g/gaia/pull/5854
I've attached the PR to Bug 794680 and ask for r? to Vivien.
Assignee | ||
Comment 18•12 years ago
|
||
Closing. See Bug 794680.
Status: NEW → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Comment 19•12 years ago
|
||
Talked to Zach about this in b2gpay - duping instead.
Resolution: FIXED → DUPLICATE
Updated•12 years ago
|
blocking-basecamp: + → -
Updated•12 years ago
|
No longer blocks: basecamp-id
You need to log in
before you can comment on or make changes to this bug.
Description
•