Bug_43229: Disable opening links before torbrowser is bootstrapped, preventing the app from entering a bad state and add functionality for what to do instead
Merge Info
Related Issues
Backporting
Timeline
-
Immediate: patchset needed as soon as possible -
Next Minor Stable Release: patchset that needs to be verified in nightly before backport -
Eventually: patchset that needs to be verified in alpha before backport -
No Backport (preferred): patchset for the next major stable
(Optional) Justification
-
Emergency security update: patchset fixes CVEs, 0-days, etc -
Censorship event: patchset enables censorship circumvention -
Critical bug-fix: patchset fixes a bug in core-functionality -
Consistency: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc -
Sponsor required: patchset required for sponsor -
Localization: typos and other localization changes that should be also in the release branch -
Other: please explain
Merging
-
Merge to tor-browser-!fixupstotor-browser-specific commits, new features, security backports -
Merge to base-browser-!fixupstobase-browser-specific commits, new features to be shared withmullvad-browser, and security backports-
NOTE: if your changeset includes patches to both
base-browserandtor-browserplease clearly label in the change description which commits should be cherry-picked tobase-browserafter merging
-
NOTE: if your changeset includes patches to both
Issue Tracking
-
Link resolved issues with appropriate Release Prep issue for changelog generation
Review
Request Reviewer
-
Request review from an applications developer depending on modified system: -
NOTE: if the MR modifies multiple areas, please
/ccall the relevant reviewers (since gitlab only allows 1 reviewer) - accessibility : henry
- android : clairehurst, dan
- build system : boklm
- extensions : ma1
- firefox internals (XUL/JS/XPCOM) : jwilde, ma1
- fonts : pierov
- frontend (implementation) : henry
- frontend (review) : donuts, richard
- localization : henry, pierov
- macOS : clairehurst, dan
- nightly builds : boklm
- rebases/release-prep : dan, ma1, pierov, richard
- security : jwilde, ma1
- signing : boklm, richard
- updater : pierov
- windows : jwilde, richard
- misc/other : pierov, richard
-
NOTE: if the MR modifies multiple areas, please
Change Description
Added check to ensure the app is bootstrapped before opening links, preventing the app from entering a bad state (specifically a browser with the internet disabled that also can't be bootstraped without an app restart). Instead it opens a Snackbar that prompts the user to connect. If the user taps "Connect", the app will show the bootstrap screen and automatically attempt to connect (so far this is the same behavior as if the user navigated back and tapped connect manually). If the connection finishes after starting from this new entry point, the webpage that would have loaded earlier now automatically loads.
How I fixed this also partly fixes #42651 (closed) as the user is no longer forced out of the settings page once the bootstrap finishes. However, there still isn't any feedback to the user that the bootstrap finished. For future work I'm debating between a toast notification (easy) and making the progress bar visible on all screens of the app (harder).
I also partly helped set up for future connection assist work, specifically dealing with some TODO's written by @henry
I also edited the base FenixSnackbar xml to match the figma designs and also what @felicia put in a comment below
How Tested
Launch the app, but don't bootstrap. Go to settings and test that every button that would normally open a webpage, instead shows a Snackbar (as shown above). Known examples are "Donate to The Tor Project" (at the bottom of the normal settings page), the top 2 buttons in "About Tor Browser" (What's new in Tor Browser, Support, the other two are about: pages and load without internet), and "Find more extensions" in the Extensions page. Make sure that the connect button on the Snackbar properly navigates back to the bootstrap screen and properly loads the requested webpage.
Merge request reports
Activity
added Android label
requested review from @dan
assigned to @clairehurst
mentioned in issue #43229 (closed)
Resolved by Dan BallardNew issue: this needs an exemption for
about:addresses. i can't get to about:config or more importantly the htmlConnect page with this enabled- Last reply by Dan Ballard
added 19 commits
-
7a808c2e...5e9deb42 - 18 commits from branch
tpo/applications:tor-browser-128.4.0esr-14.5-1 - b0fd1a16 - fixup! [android] Modify UI/UX
-
7a808c2e...5e9deb42 - 18 commits from branch
Resolved by clairehurstI like this solution, but I was thinking if we could also provide a quick option for the user by displaying a
Connectbutton alongside the message so they don't need to go all the way back totorconnect. So I was taking a look at Firefox's components and thought that maybe the Snackbar might work for this (screenshot below).
After the user clicks on the
Connectbutton, they could be redirected totorconnectin its "connecting" state.Personally, I prefer the contrast of white on purple like the current solution. But if we decide consistency is important here, then I'd need to advocate for the Snackbar.
Edited by Felicia- Last reply by Felicia
added 47 commits
-
b0fd1a16...f8cf9f0a - 45 commits from branch
tpo/applications:tor-browser-128.4.0esr-14.5-1 - b6645d9f - fixup! [android] Add Tor integration and UI
- bf2a4661 - add to prev
-
b0fd1a16...f8cf9f0a - 45 commits from branch
added 3 commits
-
7c1030c2...4dbb3744 - 2 commits from branch
tpo/applications:tor-browser-128.4.0esr-14.5-1 - a5492e3e - fixup! [android] Add Tor integration and UI
-
7c1030c2...4dbb3744 - 2 commits from branch
marked this merge request as draft from clairehurst/tor-browser@a5492e3e
marked this merge request as draft from clairehurst/tor-browser@57ae086a
mentioned in merge request tpo/translation!131 (merged)
- Resolved by clairehurst
I'd imagine it will cause that this MR is targeting tor-browser-128.4.0esr-14.5-1 instead of tor-browser-128.5.0esr-14.5-1. What's the best way to fix it? I tried changing the branch and rebasing, but it failed on gitlab. I also tried rebasing and also merging locally but ran into a ton of issues.
- Last reply by morgan
added 365 commits
- 57ae086a...d1eed871 - 355 earlier commits
- 85faa5f2 - Bug 43340: Fetch aarch64 alphas for linux aarch64 dev builds
- c1951fdb - Bug 43340: Use the correct vendor in linux aarch64 dev builds
- f905a88c - Revert "Bug 43099: 2024 YEC"
- 035f30c6 - Revert "Bug 43098: Year End Campaign 2024."
- 395fc108 - fixup! Bug 31740: Remove some unnecessary RemoteSettings instances
- 5b8b20de - fixup! Tor Browser strings
- d8041158 - fixup! Add TorStrings module for localization
- 781f3a87 - fixup! Bug 42305: Add script to combine translation files across versions.
- 174cf42e - fixup! Add CI for Tor Browser
- 938f751c - fixup! [android] Add Tor integration and UI
Toggle commit listmarked this merge request as draft from clairehurst/tor-browser@aaaa0a99
Resolved by clairehurst@clairehurst I think in the rebase, this conflicted with !1308 (merged), but the conflicts were not properly resolved. In particular, I noticed that the YEC 2024 strings were re-added by this merge request, triggering tpo/translation!132 (merged). But maybe other parts should be checked as well.
- Last reply by clairehurst
mentioned in merge request !1309 (merged)
mentioned in merge request tpo/translation!133 (merged)
mentioned in issue #43438
