Jason Smith [:jsmith] Reporter
	Description • 12 years ago

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.

	Jason Smith [:jsmith] Reporter
	Comment 1 • 12 years ago

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.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 2 • 12 years ago

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.

	Jason Smith [:jsmith] Reporter
	Comment 3 • 12 years ago

(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?

	Jason Smith [:jsmith] Reporter
	Comment 4 • 12 years ago

(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.

	Fernando Jiménez Moreno [:ferjm] Assignee
	Comment 5 • 12 years ago

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.

	Fernando Jiménez Moreno [:ferjm] Assignee
	Comment 6 • 12 years ago

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.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 7 • 12 years ago

(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.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 8 • 12 years ago

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.

	Josh Carpenter [:jcarpenter]
	Comment 9 • 12 years ago

> 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.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 10 • 12 years ago

(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.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 11 • 12 years ago

(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?

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 12 • 12 years ago

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.

	Jason Smith [:jsmith] Reporter
	Comment 13 • 12 years ago

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