804485 - [Trusted UI] Trusted UI is showing an app:// URL - this isn't supposed to be exposed to an end-user

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P3)

Description

[Jason Smith [:jsmith]]

Attachment: Trusted UI Dialog

Build:

Device - Otoro
Hashes:

  <project name="gaia" path="gaia" remote="b2g" revision="cf533e66c4c589478f5addc53cab2d9a4853402b"/>
  <project name="releases-mozilla-aurora" path="gecko" remote="mozilla" revision="f58edfde05cb708f8a2c440d338f2e429aaf372b"/>

Steps:

1. Call mozPay with the mock payment provider

Expected:

The trusted UI should appear with no app:// shown.

Actual:

The trusted UI shows an app:// scheme in the dialog.

Comment 1

[Jason Smith [:jsmith]]

Nominating to block - thou shalt not expose the app:// protocol to end users, as they have absolutely no clue what that means. It's for internal use only.

Comment 2

[(inactive after 6/18) Alive Kuo [:alive]]

All window.open has the same tactic: display content origin.
This is not relavant to Trust UI only, but also popup manager.
If somebody finally determines app:// protocol should be hidden from the user, please supply an alternative way to display in-app window.open origin.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Alive Kuo [:alive] from comment #2)
> All window.open has the same tactic: display content origin.
> This is not relavant to Trust UI only, but also popup manager.
> If somebody finally determines app:// protocol should be hidden from the
> user, please supply an alternative way to display in-app window.open origin.

Ah gotcha. I believe when I talked with Jonas previously on this, the conclusion was reached that we should never expose the app:// protocol to end users, as they have no idea of what that means.

Josh - What's the alternative to expose popupmanager & trusted UI then?

Comment 4

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #3)
> (In reply to Alive Kuo [:alive] from comment #2)
> > All window.open has the same tactic: display content origin.
> > This is not relavant to Trust UI only, but also popup manager.
> > If somebody finally determines app:// protocol should be hidden from the
> > user, please supply an alternative way to display in-app window.open origin.
> 
> Ah gotcha. I believe when I talked with Jonas previously on this, the
> conclusion was reached that we should never expose the app:// protocol to
> end users, as they have no idea of what that means.
> 
> Josh - What's the alternative to expose popupmanager & trusted UI then?

And when I mean alternative, I mean alternative when the origin is from app:// protocol.

Comment 5

[Fernando Jiménez Moreno [:ferjm]]

It totally makes sense to avoid exposing the app:// protocol to the users. What probably want to show is the app caller name, but that requires Bug 796629 to be landed first.

Comment 6

[Fernando Jiménez Moreno [:ferjm]]

s/What probably/What we probably/

BTW, this is a slightly different case to the PopupManager. For the PopupManager we show the origin of the content embedded within the dialog. For the TrustedUIManager we show the origin of the app that triggers the dialog creation, not the origin of the content.

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #5)
> It totally makes sense to avoid exposing the app:// protocol to the users.
> What probably want to show is the app caller name, but that requires Bug
> 796629 to be landed first.

Uh, I don't think this needs 796629to land.
App caller name is a good idea and could be easily solved now.

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

https://github.com/alivedise/gaia/tree/bugzilla/804485
I have a fix for this but we have better waiting UX confirm. Josh is on PTO now so add Patryk in the loop.

Comment 9

[Josh Carpenter [:jcarpenter]]

> For the PopupManager we show the origin of the content embedded within the dialog. 

Correct.

> For the TrustedUIManager we show the origin of the app that triggers the dialog creation, not the origin of the content.

Not quite. For the TrustedUI we want to show the name of the process. eg: "Purchase SuperAlarm" (we'll confirm verbiage during string freeze copy clean up). Alberto has said this should be doable, possibly by passing through a Name.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Josh Carpenter [:jcarpenter] from comment #9)
> > For the PopupManager we show the origin of the content embedded within the dialog. 
> 
> Correct.
> 

Now the problem is the origin looks like 'app://alarm.gaia-mobile.org'.
So, do you think we could change this to the app name? `app:` can confuse somebody.

> > For the TrustedUIManager we show the origin of the app that triggers the dialog creation, not the origin of the content.
> 
> Not quite. For the TrustedUI we want to show the name of the process. eg:
> "Purchase SuperAlarm" (we'll confirm verbiage during string freeze copy
> clean up). Alberto has said this should be doable, possibly by passing
> through a Name.

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Josh Carpenter [:jcarpenter] from comment #9)
> Not quite. For the TrustedUI we want to show the name of the process. eg:
> "Purchase SuperAlarm" (we'll confirm verbiage during string freeze copy
> clean up). Alberto has said this should be doable, possibly by passing
> through a Name.

Do we always use trustedUI for purchasing? I am curious what's the API here. How does an app tell the system app the 'action'? The string should be translated/l10ned in the system app, but it's defined/passed in the user app.
Alberto, would you mind to clarify? It seems this bug should be considered separately about popup manager and trustedUI manager. How about filing another bug for trustedUI?

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

I am going to deassign myself and popup manager case work would be done in my another patch. Leave this bug to trustUI owner and rename the bug title.

Comment 13

[Jason Smith [:jsmith]]

This appears to be fixed with the new animations + trusted UI patches.