Several key improvements to the user experience in the current AitC implementation can be made, but this bug will focus on the two key aspects: - When the user is actively looking at the dashboard, if we are not able to obtain an assertion for any reason, the user must be notified. - Currently, if the user is logged out, or we could not figure out which email was used by them at the marketplace, a BrowserID popup is presented when the user visits the dashboard. This experience can be streamlined by instead injecting a button into the dashboard content, and making login an explicit action by the user. (This needs changes to the BrowserID module from Bug 745345).

Instead of injecting a bug, can we do something more cooperative with the dashboard? That would fit better with the HTML implementation as well (which can't do any injection). Maybe we can hang a new thing off mozApps.mgmt.

Agreed! Here's a straw-man proposal: DOMRequest mozApps.mgmt.getUserInfo() - Returns the user currently associated with the local DOMApplicationRegistry, null if no user is set (default user?). DOMRequest mozApps.mgmt.setUserInfo() - Sets the current logged in user. All calls to mozApps.* after a setUserInfo() will now refer to the apps in that user's DOMApplicationRegistry only. The dashboard can use both of these methods to implement a clean login UI. Should we mandate the arguments/return-value to be BrowserID assertions or a derivative of some sort?

Anant - Could we break this bug down into separate smaller bugs? Sounds like you are describing multiple tasks in regards to this bug.

I don't think setUserInfo() will work - the assertion shouldn't go through the dashboard at all, for instance. I think instead the dashboard should just request that login start (and then the dashboard can bind that to a login button), and have an event that comes back when login happens. Well... another approach entirely that I was kind of expecting for the HTML implementation and dashboard is we simply block entirely on login, refusing to show the dashboard unless you log in. This still requires some API, but a simpler API. This also has the advantage of working nicely with the HTML implementation (and avoiding popup blockers and whatnot).

We should get UX feedback on the login flow, from the perspective of a dashboard.

I'm not really comfortable by adding this kind of explicit calls to mozApps. Looks a lot like the "localstorage" from the early days. Wouldn't this be solved by "login in the browser" in a more elegant way?

(In reply to Fabrice Desré [:fabrice] from comment #6) > Wouldn't this be solved by "login in the browser" in a more elegant way? Login to the browser is very useful, but only for the native FF implementation. I don't see a way to support the HTML5 mode of the dashboard without adding an explicit mozApps call. Any creative ideas?

The tension here I think is that we would like to display aitc status, errors, login state, etc., in content (i.e., in the dashboard), despite the fact that it runs in chrome. The reason to keep it in content is, I think, mostly to avoid adding anything to the Firefox interface when we have a more appropriate and discoverable context available. If it's only for the HTML5 implementation, I'm personally fairly comfortable adding that functionality under an HTML5-only attribute (e.g., mozApps.mgmt.htmlImplementation.loginStatus()) - but I think the issues may be more general.

(In reply to Ian Bicking (:ianb) from comment #8) > The tension here I think is that we would like to display aitc status, > errors, login state, etc., in content (i.e., in the dashboard), despite the > fact that it runs in chrome. The reason to keep it in content is, I think, > mostly to avoid adding anything to the Firefox interface when we have a more > appropriate and discoverable context available. I think further down the road we'll be able to move the login status to chrome. BrowserID login in the URL bar was one prototype, for example. The only reason I proposed an injection method in this bug is because adding chrome UI needs mockups and approval from the Ux team on various products, which may not happen in time for Fx 15. > If it's only for the HTML5 implementation, I'm personally fairly comfortable > adding that functionality under an HTML5-only attribute (e.g., > mozApps.mgmt.htmlImplementation.loginStatus()) - but I think the issues may > be more general. Interesting, we should definitely consider this if we feel we can solve the issues in the native client without adding a new call!

No concrete plans to ship AITC, so marking this as WONTFIX. We can reopen if that decision changes.