Clicking on cog/gear icon crashes Tor Browser for Android

it is on the first screen, the one shaped like a cog at upper right. when I click it I get a white page and an android message saying tor browser stopped working and when I click ok on that message tor browser crashes.

For the whole thread about narrowing this bug down, see: https://blog.torproject.org/comment/280338#comment-280338

added TBA-a3 TorBrowserTeam201905 blog component::applications/tor browser owner::tbb-team priority::very high resolution::fixed severity::normal status::closed tbb-8.5-must tbb-mobile type::defect user-feedback labels

I tried reproducing this on an Android 6.0 emulator, emulating both x86 and armv7 architectures. The app didn't crash when clicking on the settings cog during either test. It sounds like the crash is occurring during the transition between the bootstrapping screen (using the BrowserApp as the Activity) to the first preferences screen (using the TorPreferences Activity).

There aren't too many places where this can crash within the app code (verses within system code), however we are making some assumption about variables and return values being non-null in the TorPreferences code. Maybe some of those assumptions are wrong, and the code should correctly handle these. I'll fix these potential issues, at least.

Trac:
Status: new to needs_information

We believe this is fixed with commit fd7cccb3f4a908ff38edfefc36b194666c886f69 on tor-browser-60.6.1esr-8.5-1 and will be available in the next alpha release (8.5a11). If you still see the crashes with that version, please reopen the ticket.

Trac:
Resolution: N/A to fixed
Status: needs_information to closed

Still an issue, although slightly different now: https://blog.torproject.org/comment/281010#comment-281010

Trac:
Status: closed to reopened
Keywords: tbb-8.5-must-alpha deleted, tbb-8.5-must added
Parent: #28329 (moved) to N/A
Resolution: fixed to N/A

Quoting from the blog comment:

[...] the tor settings page is white and torbrowser freezes. not a significant
difference, I only have to terminate torbrowser manually now when its stuck in
that white page.

I wonder if #30214 (moved) is the underlying bug of this.

removing ux team for now

Trac:
Keywords: ux-team deleted, N/A added

Moving tickets to May

Trac:
Keywords: TorBrowserTeam201904 deleted, TorBrowserTeam201905 added

Replying to sysrqb:

Quoting from the blog comment: {{{ [...] the tor settings page is white and torbrowser freezes. not a significant difference, I only have to terminate torbrowser manually now when its stuck in that white page. }}}

I wonder if #30214 (moved) is the underlying bug of this.

Does not seem to be the case. Recent nightlies still seem to have this problem. I try to get more debug information.

Indeed. This was a simple and silly bug. When using an older Android versions on a tablet (or other large-screen device), Android tries creating a preference "flow", where it first shows a panel containing only headers (title and summary), then the user selects one of the headers and Android shows the real preference screen. We didn't implement the initial headers screen because it wasn't part of our goal (we really only targeted smaller devices, too).

On newer versions of Android, the preferences are shown regardless of whether the headers are defined (so it handles our implementation well enough). On older versions of Android, I assume the user is shown all the defined headers - in our case, there are zero headers and therefore a blank screen is shown. This patch tells Android it should skip the headers and go straight to the fragment we define on the line above it.

Branch bug29982 in my repo.

Trac:
Status: reopened to needs_review

Replying to sysrqb:

Branch bug29982 in my repo. BTW, if you want to get a review from the Tor Browser team, you should set TorBrowserTeam201905R keyword.

Trac:
Username: nobell

Replying to sysrqb:

Indeed. This was a simple and silly bug. When using an older Android versions on a tablet (or other large-screen device), Android tries creating a preference "flow", where it first shows a panel containing only headers (title and summary), then the user selects one of the headers and Android shows the real preference screen. We didn't implement the initial headers screen because it wasn't part of our goal (we really only targeted smaller devices, too).

On newer versions of Android, the preferences are shown regardless of whether the headers are defined (so it handles our implementation well enough). On older versions of Android, I assume the user is shown all the defined headers - in our case, there are zero headers and therefore a blank screen is shown. This patch tells Android it should skip the headers and go straight to the fragment we define on the line above it.

Branch bug29982 in my repo.

Nice find! The change looks good to me and I applied it tor tor-browser-60.6.1esr-8.5-1 (commit 6a6052976627429027602a3b6871f0ae37aaa36d) and tor-browser-60.6.1esr-9.0-1 (commit b914bb89ff0d07765c29a11ead947315f1e6d054).

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

There was a comment about this bug here: !https://blog.torproject.org/comment/281010#comment-281010

Trac:
Keywords: N/A deleted, blog, user-feedback added

closed

mentioned in issue #30214 (moved)

moved to tpo/applications/tor-browser#29982 (closed)