Trac: Keywords: N/Adeleted, tbb-torbutton, TorBrowserTeam201807 added Parent: N/Ato#26531 (moved) Priority: Medium to Very High Owner: N/Ato tbb-team Component: Applications/Torbutton to Applications/Tor Browser
XUL doesn't work well on mobile, so I implemented the mobile preferences in XHTML.
Initially, I tried to make the code reusable across the mobile and desktop, however I was losing lot of time trying to make the Desktop version work. So this patchset has just the mobile implementation.
Nice! How can we test that? I.e. how is it integrated into the .apk (build process)?
It is not integrated in the build process. You need to copy the xpi to the distribution directory(mobile/android/torbrowser/assets/distribution/extensions).
Besides that you will need to update the extension preferences info:
extensions.enabledAddons: Update the torbutton version to 2.0.1
extensions.legacy.enabled: It needs to be true
I wonder if we can integrate it in the work made by sisbell.
Nice! How can we test that? I.e. how is it integrated into the .apk (build process)?
It is not integrated in the build process. You need to copy the xpi to the distribution directory(mobile/android/torbrowser/assets/distribution/extensions).
For this
export TB_BUILD_WITH_DISTRIBUTION=1 (or set this env variable however you like) so the distribution is included by .mozconfig-android
create mobile/android/torbrowser/assets/distribution/extensions, as igt0 said, if that directory structure doesn't already exist, and copy the xpi into the extensions directory.
XUL doesn't work well on mobile, so I implemented the mobile preferences in XHTML.
Initially, I tried to make the code reusable across the mobile and desktop, however I was losing lot of time trying to make the Desktop version work. So this patchset has just the mobile implementation.
The original XUL implementation still works on Desktop, correct? Only mobile uses XHTML?
Oh, right. Okay, i got this working by toggling xpinstall.signatures.required. Then I forced installation by going to file:///data/data/org.torproject.torbrowser/distribution/extensions/ and tapping on torbutton@torproject.org.xpi. After restarting the app, torbutton runs and I see "Security Settings" in the menu. igt0, nice job.
When I open the Security Settings, I see the slider. However, tapping the actual label "Standard" and "Safest" result in the position jumping to the other location (tapping on "Standard" causes the location indicator to jump to "Safest", and vice versa). I think the noscript settings are reversed, as well.
XUL doesn't work well on mobile, so I implemented the mobile preferences in XHTML.
Initially, I tried to make the code reusable across the mobile and desktop, however I was losing lot of time trying to make the Desktop version work. So this patchset has just the mobile implementation.
The original XUL implementation still works on Desktop, correct? Only mobile uses XHTML?
needs to get reworded.
c) If there is an error in get_general_useragent_locale() we should have some way of showing it (e.g. by emitting a message to the console), even if the usual logging functionality is not available in the module. I'd like to avoid omitting any kind of notification in such a case.
I am not sure, because legacy extensions are not supported by default in Fennec and I believe the targetApplication is a way to protect the user of installing it in unsupported versions. So even if the user tries to install just the torbutton, Fennec will not allow it.
Let's keep the loglevel to 4 as we had it in the original code. And probably add err to the log string to give some clue about what went wrong? I guess just the "Error while getting locale" + err would do it.
Trac: Status: needs_review to needs_revision Keywords: TorBrowserTeam201808R deleted, TorBrowserTeam201808 added
Thanks, looks good. We are close here. Could you do a final rebase of your patches against master? There are a bunch of conflicts due to the desktop onboarding/about:tor-changes.
Thanks, looks good. We are close here. Could you do a final rebase of your patches against master? There are a bunch of conflicts due to the desktop onboarding/about:tor-changes.
Alright, I set the slider to "safest" and went to the test on ip-check.info and still, it shows that JavaScript is enabled. Can anyone confirm this result?
The second question: What is the planned way to actually deliver this feature to users given that we won't send them to about:config? It seems there is a patch missing for that?
Alright, I set the slider to "safest" and went to the test on ip-check.info and still, it shows that JavaScript is enabled. Can anyone confirm this result?
I tested with the patch for #27220 (moved) and still got the same results. Here is the bundle I used:
The second question: What is the planned way to actually deliver this feature to users given that we won't send them to about:config? It seems there is a patch missing for that?
While looking at #27221 (moved) I copied an .xpi with this fix over an older Torbutton version and the browser on desktop is not showing the about:tor page anymore. It's complaining about the torbutton logger not available yet (undefined reference error). Thus, we need a better fix here.
Alright, I set the slider to "safest" and went to the test on ip-check.info and still, it shows that JavaScript is enabled. Can anyone confirm this result?
I tested with the patch for #27220 (moved) and still got the same results. Here is the bundle I used:
The second question: What is the planned way to actually deliver this feature to users given that we won't send them to about:config? It seems there is a patch missing for that?
Arthur noticed we don't need the torbutton_get_general_useragent_locale because the getLocale does the exactly same thing and it is simpler. So I removed torbutton_get_general_useragent_locale.
Damn, I should have tested it again:
{{{
JavaScript error: chrome://torbutton/content/torbutton.js, line 2251: TypeError: show_torbrowser_manual is not a function
}}}
this happens on a desktop Tor Browser (8.0a10 Linux).
Okay, I think what happened was me testing the commit before bumping the Torbutton version and then later, after tagging, I saw the error. Blowing the startupCache away manually "solves" this problem. igt0 verified that an actual version bump has the same effect. Thus, we are good here it seems and can proceed with 2.0.3.
Trac: Status: reopened to closed Resolution: N/Ato fixed