Opened 2 years ago

Closed 10 months ago

#20815 closed task (fixed)

UI dev work of security slider experience on Orfox

Reported by: isabela Owned by: synzvato
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-mobile, android
Cc: gk, tbb-team, n8fr8, amoghbl1, brade, mcs, arthuredelstein, synzvato, fdsfgs@… Actual Points:
Parent ID: #24855 Points:
Reviewer: Sponsor:

Description

Project reference: https://trac.torproject.org/projects/tor/wiki/org/teams/ApplicationsTeam/TorBrowserAndroid/Roadmap

Contract would start with 25hrs of work.

UI Work description:
Port or reimplement Tor Browser "Security Slider" user interface to Firefox Add-on SDK for user on Orfox/Firefox Android
Design of user interface will need to be updated to support more "responsive" mobile design and layout
Implementation will call into methods against dummy/skeleton code for actual logic
UI must be internationalized/localized to support same string resources from TB Security Slider
Test implementation within Orfox on Android

Security Slider specs and docs can be found at:
https://trac.torproject.org/projects/tor/ticket/9387#comment:82
https://blog.torproject.org/blog/tor-browser-45-released
https://people.torproject.org/~mikeperry/images/SecuritySlider.jpg

Wireframes for the experience we want to build:

https://trac.torproject.org/projects/tor/ticket/20291


Child Tickets

Change History (9)

comment:1 Changed 2 years ago by isabela

Summary: FE part of security slider experience on OrfoxUI dev work of security slider experience on Orfox

comment:2 Changed 2 years ago by arthuredelstein

Cc: arthuredelstein added

comment:3 Changed 2 years ago by synzvato

Cc: synzvato added

comment:4 Changed 2 years ago by synzvato

Owner: changed from tbb-team to synzvato
Status: newassigned

comment:5 Changed 2 years ago by synzvato

Tor Browser Settings source code repository:
https://git.synz.io/synzvato/tor-browser-settings/tree/master

I was originally planning on defining an options page. This is a modern way of making preference pages that have full API-access and that can be shown programmatically. However, WebExtensions doesn't yet allow add-ons to add menu items to the Firefox for Android menu. That's why a mix of WebExtensions and Add-on SDK would have been neat.

For now it's impossible to embed WebExtensions code into our Add-on SDK extension. This is due to the fact that the current stable version of Orfox is based on Firefox for Android 45.5.1 ESR. Support for embedded WebExtensions was first introduced in version 51. This is worth keeping in mind, though, as the next ESR-release will be 52.

That's when I started to look into XUL. This language was used to build the TorButton settings screen, but it has since been deprecated. During my tests, I found that controls like responsive sliders didn't turn out well on mobile. I was also worried about the amount of effort it would take to later port this to WebExtensions. I decided to let go of the idea.

Taking everything into account, the cleanest and most future-proof solution appears to be writing the settings page in HTML5, and to implement custom workarounds for localizations and Add-on SDK API interaction. The add-on injects a content script into the settings page. The code emits and handles events, and alters the DOM when needed.

The high-level tabs API is not too keen on opening Chrome URLs. That's why I was forced to fall back to some lower-level APIs, for bringing up the settings page when a user clicks the Orfox Settings menu entry.

I have also looked into several possibilities for persisting preferences and concluded that the Add-on SDK's:

  • high-level simple-prefs API could be an option if we will not be altering preferences that lie outside of the scope of the add-on, and if we're fine with defining hidden settings within our package.json;
  • high-level simple-storage API is probably not a viable solution for storing our preferences. It seems to work sort of like DOM storage, but it's scoped to a specific add-on, instead of a website;
  • low-level preferences/service is the most flexible, and least opinionated, alternative. It's dynamic, since it does not rely on pre-defined package.json entries, and can operate outside of the add-on's scope.

comment:6 Changed 2 years ago by synzvato

Type: defecttask

comment:7 Changed 21 months ago by tokotoko

Cc: fdsfgs@… added

comment:8 Changed 10 months ago by sysrqb

Parent ID: #24855

comment:9 Changed 10 months ago by isabela

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.