[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #20815 [Applications/Tor Browser]: UI dev work of security slider experience on Orfox

#20815: UI dev work of security slider experience on Orfox
--------------------------------------+--------------------------
 Reporter:  isabela                   |          Owner:  synzvato
     Type:  defect                    |         Status:  assigned
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-mobile, android       |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (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 [https://developer.mozilla.org
 /en-US/Add-ons/WebExtensions/Anatomy_of_a_WebExtension#Options_pages
 options page]. This is a modern way of making preference pages that have
 full API-access and that can be shown programmatically. However,
 WebExtensions [https://bugzilla.mozilla.org/show_bug.cgi?id=1268020
 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
 [https://developer.mozilla.org/en-US/Add-
 ons/WebExtensions/Embedded_WebExtensions embedded WebExtensions] was first
 introduced in version `51`. This is worth keeping in mind, though, as
 [https://www.mozilla.org/en-US/firefox/organizations/faq/ 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
 [https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-
 firefox-add-ons/ 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 [https://developer.mozilla.org/en-US
 /Add-ons/SDK/Guides/Content_Scripts content script] into the settings
 page. The code emits and handles events, and alters the DOM when needed.

 The high-level [https://developer.mozilla.org/en-US/Add-ons/SDK/High-
 Level_APIs/tabs tabs API] is not too keen on opening
 [https://developer.mozilla.org/en-
 US/docs/Mozilla/Tech/XUL/Tutorial/The_Chrome_URL Chrome URLs]. That's why
 I was [https://git.synz.io/synzvato/tor-browser-
 settings/blob/master/src/main.js#L47 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 [https://developer.mozilla.org/en-US/Add-ons/SDK/High-
 Level_APIs/simple-prefs 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 [https://developer.mozilla.org/en-US/Add-ons/SDK/High-
 Level_APIs/simple-storage 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 [https://developer.mozilla.org/en-US/Add-ons/SDK/Low-
 Level_APIs/preferences_service 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20815#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs