Connectivity: wifi SIM used: telcel SIM (55650-62732) device: Inari/1.1 test app used: (onlyboku) on iStage steps to reproduce: 0. User is logged in 1. Search for paid app on bangoandboku or onlyboku "Pricetier15" 2. Start the purchase flow 3. Enter PIN 4. on the payment screen is not possible to open the links " Terminos y asistencia" and " "como funciona" Expected behavior: the links should works on the payment screen Actual behavior: Is not possible to open the links that found in the bottom on the screen payment reproducible: yes

Also affects Flame 2.0 Note: On Flame 2.0 using data connectivity, when those hyperlinks are clicked, the native interface denotes data traffic activity.

> Note: On Flame 2.0 using data connectivity, when those hyperlinks are clicked, the native interface denotes data traffic activity. I see clicking those links is sending a request to google analytics.

When I tested this, I noticed that the default behavior is to open a new tab to display the contents for each link. If the customer clicks "Back" (not sure how this works on Firefox OS, as I don't have a Firefox phone to test with), the tab is automatically closed and the customer is returned to the payment panel screen. The URLs are as follows: Terms & Conditions: https://buy.boku.com/mobile_web_terms/86eae42f11f2ef0913599aa9/go.html?&c=MX&l=ES How it Works: https://buy.boku.com/mobile_how_it_works/86eae42f11f2ef0913599aa9/go.html?&c=MX&l=ES

Hi John. You can use the Firefox OS Simulator to reproduce the issue: https://developer.mozilla.org/en-US/docs/Tools/Firefox_OS_Simulator

video shows how the links don't work within the app.

I'll take this to investigate that target attribute removal is enough for the links to work.

Here's the code I tested with using a mock provider to load the HTML in the trusted UI. https://dpaste.de/Py36 Screencast: https://www.dropbox.com/s/pourxg3h1szjpli/VID_20150226_204547.mp4?dl=0 (Please excuse the shonky camera work).

@Stuart, thank you for confirming. Raised with Product team via ticket #DIRECTTOBILL-12026. Please stay tuned, and let me know if you concoct any workarounds / implementation changes on your end.

I've raised the following platform bug: see bug 1138387. This bug has a complete set of instructions + test-case which might be useful for your testing (I note the pastebin link in comment 11 has already expired) see http://yakshavings.co.uk/trusted-ui/ for further info.

Our team proposed the following fix for this issue: Can we open new links in a new window with JavaScript? For example, 1.) Remove 'target' attribute (as previously requested) 2.) window.open opens new window instance for "How it Works" and "T&C" 3.) Note: This solution will not work for other links (i.e. Zendesk customer service URLs, carrier websites that are displayed in certain markets) If this solution is suitable, we will need to acquire: a.) Unique Firefox OS useragent for browser detection purposes b.) A Firefox OS test phone Please let me know and I will raise it with our team. Thanks for your insights!

Thanks for spearheading this John. I'll review with the team and see if this works.

Sadly, no, because by default window.open opens a new window. https://developer.mozilla.org/en-US/docs/Web/API/Window/open If window.open could be made to open in the current browsing context, that might work, but since you are opening something in the current window, window.location is easier. You don't have the option of opening any new windows, just changing the location of the existing ones. In comment 13 Stuart provided instructions on how to test this with some great instructions. I altered it slightly to test out window.open here: http://www.agmweb.ca/files/trusted-ui.html Here's a video: https://www.dropbox.com/s/xy39ejzd3kk76nw/window.open.mov?dl=0 with target fails, window.open fails without target works, window.location works

Andy + Stuart: To clarify, simply removing the 'target' attribute would fix this issue?

Caveat: I haven't read your code in detail, but yes we believe so. The only issue then, as discussed, is that the links become dead ends, there's no back button, no way to re-enter the flow. You have to cancel and start again, going through the multiple PINs. That's not going to be great for the conversion rate. But how big a problem that is and what's acceptable I'll let others comment.

This seems like the best of two evils. Though it is certainly not an ideal flow, only those who go to the link will be affected. Does Boku have any numbers on the average % of people who enter the flow and click on one of the bottom buttons?

Hi Mozilla Team, Thank you for confirming. I have followed up with our product team to see if they have any metrics on customers who clicked the "How it Works" and "Terms and Conditions" links, as I can't locate any data in our log files. However, it should be noted that a determined customer will likely close the window (if they can't back out) and initiate another Boku transaction. Is there a browser user agent string that can be used to provide the requested change to Mozilla Firefox OS users? Lastly, does Mozilla have any plans to change the trusted browser interface behavior in the future (and possibly provide it with more enhanced display functionality for more complex scenarios like this)?

To follow up with Comment 20, are there plans to implement features like a back button or new window functionality for the trusted browser interface in the future?

Please note that bug 1138387 was filed in comment 13 asking for feedback from the platform team on this issue.

Our engineering team wanted to confirm, as they are currently scoping the resources and timeline for this fix: This issue will be resolved if the current 'target' attribute is removed Additionally, is there a user agent string that we can use to identify the affected Firefox OS browser? Thank you!

(In reply to John Tan [Boku Merchant Support] from comment #23) > Our engineering team wanted to confirm, as they are currently scoping the > resources and timeline for this fix: This issue will be resolved if the > current 'target' attribute is removed This was already confirmed in comment 11. > > Additionally, is there a user agent string that we can use to identify the > affected Firefox OS browser? > This is the code used by the marketplace for detecting FFOS. https://github.com/mozilla/marketplace-core-modules/blob/master/core/capabilities.js#L58 > Thank you!

(In reply to John Tan [Boku Merchant Support] from comment #23) John, as previously mentioned see http://yakshavings.co.uk/trusted-ui/ for detailed instructions on how to test your changes in the trusted-ui. This will enable you run your code in a trusted UI either with a device if you have one or via the simulator. Email me directly if you need help or something isn't working (Note I'm in the UK from a timezone perspective). For future reference if you need a quick response on bugs please use the "needsinfo" feature of bugzilla as that's a more visible way of flagging that the bug needs an answer. See below the commment form - check the "Need more information from" and select the drop down. Alternatively you can enter the email address or a short name e.g. :muffinresearch will find me (It's find as you type).