#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs