796185 - Terms, Privacy Policy and Learn more links don't work on B2G

Status: RESOLVED INVALID

(Core Graveyard :: Identity, defect)

Description

[Ben Francis [:benfrancis]]

The Terms, Privacy Policy and Learn more links on the login screen of the Marketplace app don't work for me, do they try to open a new window or something?

Comment 1

[Wil Clouser [:clouserw]]

Yes, they open new windows (which should work).  Talked to Dietrich, -> b2g

Comment 2

[Ben Francis [:benfrancis]]

Actually I would expect it not to work. The login screen is already in a new window created via window.open, and the Privacy Policy and Terms are trying to open in another new window.

Apps in B2G can open one and only one additional window via window.open.

Comment 3

[Potch [:potch]]

Hm. We don't really have a whole lot of control over how that UI is presented- it's powered by Persona.

We should probably loop them in, as any site that provides those links will have the same problem.

Comment 4

[Wil Clouser [:clouserw]]

Yeah, I was searching for the right component.  I guess Core::Identity?

Comment 5

[Wil Clouser [:clouserw]]

Also might be solved by 794680

Comment 6

[Jason Smith [:jsmith]]

Reason for nom - I get the feeling users should be able to get access to terms, privacy policy, etc on device for persona. Also - we're exposing UI that doesn't work on device since you can't do a pop-up within a pop-up.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #6)
> Reason for nom - I get the feeling users should be able to get access to
> terms, privacy policy, etc on device for persona. Also - we're exposing UI
> that doesn't work on device since you can't do a pop-up within a pop-up.

Ben - Do you agree or disagree that this blocks v1 ship?

Comment 9

[Sean McArthur [:seanmonstar]]

Maria: the proposed solution of loading the ToS and PP in iframes has deep security implementations (frame busting) and weird flows (x-frame-options: deny).

How would you feel if we simply opened the links in a standard Firefox window. The dialog should still be available if you go back.

Comment 10

[Maria Sandberg [:mushi]]

(In reply to Sean McArthur [:seanmonstar] from comment #9)
> Maria: the proposed solution of loading the ToS and PP in iframes has deep
> security implementations (frame busting) and weird flows (x-frame-options:
> deny).
> 
> How would you feel if we simply opened the links in a standard Firefox
> window. The dialog should still be available if you go back.

Just spoke to jsmith about this. My proposals in order of 1 being happiest UX path and 3 being least happy UX path are:

1. Clicking ToS and PP link from Persona sign in within trusted UI "expands" the sign in screen with the full text of the ToS and PP (inline iframe). This would mean that the page would have to scroll within the trusted UI. 

2. Clicking ToS and PP link from Persona sign in within trusted UI opens a full screen "popup" that covers the trusted UI and contains the full text. The user can close this popup and will be returned to the sign in screen and trusted UI. 

3. Clicking ToS and PP link from Persona sign in within trusted UI opens the links in the browser. This path is the least happy one because it is taking the user away from their context and they would have to exit the browser and reopen the Marketplace app to return to the sign in screen. 

I'm starting an email thread about this to figure out what is technically feasible and we'll make a decision from there.

Comment 11

[Kumar McMillan [:kumar]]

if we need to x-frame allow *persona.org and *personatest.org that is easy enough

Comment 12

[Sean McArthur [:seanmonstar]]

kumar: That helps for when Marketplace calls nav.id.request(), but not when some other website on the net does. I'm more worried about loading their pages into an iframe in a privileged dialog.

Comment 13

[Ben Francis [:benfrancis]]

(In reply to Jason Smith [:jsmith] from comment #8)
> Ben - Do you agree or disagree that this blocks v1 ship?

That's not my call, a group decision should be made during a triage session. I don't know if anyone triages blocking-basecamp? for this component though?

Comment 14

[Ben Adida [:benadida]]

BenF: that was probably meant for me and I took too long to respond, thus creating confusion.

Jason, yes, I think this blocks v1. Legal requirement to present these properly.

Comment 15

[Jason Smith [:jsmith]]

(In reply to Ben Adida [:benadida] from comment #14)
> BenF: that was probably meant for me and I took too long to respond, thus
> creating confusion.
> 
> Jason, yes, I think this blocks v1. Legal requirement to present these
> properly.

Okay, sounds good. Feel free to flip the flag to a + then.

Comment 17

[Dietrich Ayala (:dietrich)]

No update in a month. Sean, what the estimate for fixing this?

Comment 18

[Sean McArthur [:seanmonstar]]

The ToS and PP should be showing in an iframe, currently (as part of the native module).

I don't know what happens when Learn More is clicked, I have no device.

Comment 19

[Dietrich Ayala (:dietrich)]

None of the three links work on the device. Are you testing in desktop? I tested in the Simulator and it didn't work there either.

Comment 20

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

(In reply to Dietrich Ayala (:dietrich) from comment #19)
> None of the three links work on the device. Are you testing in desktop? I
> tested in the Simulator and it didn't work there either.

Hi, Dietrich,

I don't know if this is part of the problem you're encountering, but one thing is that the native identity still has to be preffed on:

https://bugzilla.mozilla.org/show_bug.cgi?id=811528#c3

I'll know more as soon as m-c finishes building.
j

Comment 21

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 22

[Dietrich Ayala (:dietrich)]

No input for 2.5 weeks. Sean, if you're not working on this, can you unassign?

Jed, are you saying that Sean was testing with native preffed on?

Comment 23

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

(In reply to Dietrich Ayala (:dietrich) from comment #22)
> No input for 2.5 weeks. Sean, if you're not working on this, can you
> unassign?
> 
> Jed, are you saying that Sean was testing with native preffed on?

Sean works remotely and has been waiting to receive a device.  He can't do much until that arrives.  Can anyone push that along?

Comment 24

[Sean McArthur [:seanmonstar]]

@dietrich: I was testing this on Firefox for Android (as my device seems to still be pending shipping), and using the dialog from https://notoriousb2g.personatest.org. This is the same dialog that is used by native identity, but I guess that requires the preference to be switched on?

Comment 25

[Jason Smith [:jsmith]]

(In reply to Sean McArthur [:seanmonstar] from comment #24)
> @dietrich: I was testing this on Firefox for Android (as my device seems to
> still be pending shipping), and using the dialog from
> https://notoriousb2g.personatest.org. This is the same dialog that is used
> by native identity, but I guess that requires the preference to be switched
> on?

Can you try testing this with the FF OS simulator for now? In short, the problem here is that FF OS does not support a pop-up within a pop-up. 

Although I think this bug might be server-side only. If it is, we should untrack this for basecamp and move this into your BID github, as this doesn't inherently impact on device ship.

Sean - This is a bug in the hosted code, right?

Comment 26

[Sean McArthur [:seanmonstar]]

These links are controlled by JS in the dialog, which is loaded from a server, yes.

Comment 27

[Jason Smith [:jsmith]]

Moved to https://github.com/mozilla/browserid/issues/2879.

Comment 28

[Ben Adida [:benadida]]

(In reply to Jason Smith [:jsmith] from comment #27)
> Moved to https://github.com/mozilla/browserid/issues/2879.

The only thing I would add here is that we had agreed that we would get a fully functional flow done for basecamp. I wonder if it's a good idea to stop tracking this here so soon?

Comment 29

[Jason Smith [:jsmith]]

(In reply to Ben Adida [:benadida] from comment #28)
> (In reply to Jason Smith [:jsmith] from comment #27)
> > Moved to https://github.com/mozilla/browserid/issues/2879.
> 
> The only thing I would add here is that we had agreed that we would get a
> fully functional flow done for basecamp. I wonder if it's a good idea to
> stop tracking this here so soon?

Well, let's separate two pieces:

1. Getting the on-device stuff working
2. Getting the full flow working

The on-device stuff (say nav.id) needs to be signed off by Jan 15th. The full flow doesn't have to be completely finished until the device is ready to go live, although the date pieces here is dependent on other schedules I probably don't know about (such as marketplace dependencies).