Trusty UI should notify caller when it has been closed by user action (canceled)

RESOLVED FIXED in B2G C4 (2jan on)


Firefox OS
5 years ago
5 years ago


(Reporter: jedp, Assigned: jedp)


B2G C4 (2jan on)

Firefox Tracking Flags



(Whiteboard: [qa-])


(1 attachment)

The Trusty UI does not currently notify the application that has opened it when it is closed by user action (i.e., canceled); it should.

I think an onCancel callback as the optional last argument to the open() method would be the cleanest way to provide this functionality: It is simple to understand and use, and it doesn't require any change to existing code that calls the Trusty UI now.
Strangely enough this problem does not reproduce with mozPay after we fix it's equivalent bug on this problem.
Component: General → Gaia::System
Since the work week is *fix all the blockers!* policy I'm ccing a few people who might steal this bug while Jed sleeps tonight to fix this, given that it blocks a blocker.
(In reply to Jason Smith [:jsmith] from comment #2)
> Since the work week is *fix all the blockers!* policy I'm ccing a few people
> who might steal this bug while Jed sleeps tonight to fix this, given that it
> blocks a blocker.

Thanks, Jason :)  Yes, I am just hitting the sack.  But I think the fix for this could look like this:

What do people think?  If it seems ok, I'll submit a PR first thing in the morning.  Otherwise, please feel free to take it and improve.

Thanks! Cheers,
Sorry, I missed Bug 823751.

We already have a notification about a closed trusted UI at which is handled, in the case of the mozPay implementation, at We might need the same handler for the identity side.

For the case of mozPay, the application gets the notification of a closed trusted UI via the 'onerror' event that it is fired over the 'DOMRequest' returned by the 'mozPay()' call.

Yours sound like a good solution for the Gaia side, since the caller app would be notified about the trusted UI being closed, but closing the trusted UI might also require triggering some cleanup for the chrome implementation that triggered the creation of the trusted UI at first, so we might still need this content event sent back to the chrome implementation.
Btw - bug 828182 just got filed that sounds related to this bug. Are they related? Should we do one bug and not the other?
Already replied via IRC, bug 828182 is independent from this one.
Thank you for mentioning the chrome events - they are very important and should be emitted separately for each caller within the destroy loop (here:
Oh wait, actually that already happens: _destroyDialog() calls close() for each, and close() calls _closeTopDialog(), which sends the error message.

But this means that the errorMsg is sent whenever TrustedUIManager.close() is called, which is semantically confusing to me.

Having spoken with Fernando on IRC, we've agreed that the errorMsg should be emitted from the _destroyDialog loop, and not _closeTopDialog.  This means that the errorMsg will not be emitted when TrustyUIManager.close() is called in payment.js, which he says is ok.
Created attachment 700012 [details]
Link to PR 7453

Thanks again for talking this over with me on IRC.
Attachment #700012 - Flags: review?(ferjmoreno)


5 years ago
Whiteboard: [qa-]


5 years ago
Depends on: 829176


5 years ago
No longer depends on: 829176
Target Milestone: --- → B2G C4 (2jan on)
You need to log in before you can comment on or make changes to this bug.