We probably want to create a trusted UI component that can be used to trigger the UI from chrome code and might also add some other valuable functionality to it, like an API to control (hide/show) the trusted UI from the embedded content.
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #0) > We probably want to create a trusted UI component that can be used to > trigger the UI from chrome code and might also add some other valuable > functionality to it, like an API to control (hide/show) the trusted UI from > the embedded content. Just to note - this isn't a v1 blocker, this is basically creating a "cleaner" solution for the trusted UI solution such that we reuse a singular component. If I'm wrong, please correct me.
Pointer to Github pull-request
Actually, this bug was supposed to track the platform work related to the creation of an abstract trusted UI XPCOM component, which is out of scope for v1. I've filed bug 801561 for the work related to the Gaia side of the trusted UI.
No longer blocks: 776420
ferjm - can you clarify why you think this should block for v1.1?
Actually, this probably should not block as it is a nice to have to ease the development of features that we are probably going to implement for v1.1. Sorry for the noise.
blocking-b2g: leo? → ---
tracking-b2g18: --- → ?
Since this is not a blocker, minusing for tracking, but a low risk fix can be nominated for uplift.
status-b2g18: --- → affected
tracking-b2g18: ? → -
I don't think this will ever happen. We are getting rid of the trusted UI.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.