Opened 2 months ago

Closed 5 weeks ago

Last modified 3 weeks ago

#29982 closed defect (fixed)

Clicking on cog/gear icon crashes Tor Browser for Android

Reported by: gk Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-mobile, TBA-a3, tbb-8.5-must, TorBrowserTeam201905, user-feedback, blog
Cc: antonela, igt0, tbb-team, gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

Child Tickets

Change History (11)

comment:1 Changed 2 months ago by sysrqb

Status: newneeds_information

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.

comment:2 Changed 2 months ago by gk

Resolution: fixed
Status: needs_informationclosed

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.

comment:3 Changed 7 weeks ago by gk

Keywords: tbb-8.5-must added; tbb-8.5-must-alpha removed
Parent ID: #28329
Resolution: fixed
Status: closedreopened

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

comment:4 Changed 6 weeks ago by 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 is the underlying bug of this.

comment:5 Changed 6 weeks ago by pili

Keywords: ux-team removed

removing ux team for now

comment:6 Changed 5 weeks ago by gk

Keywords: TorBrowserTeam201905 added; TorBrowserTeam201904 removed

Moving tickets to May

comment:7 in reply to:  4 Changed 5 weeks ago by gk

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 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.

Last edited 5 weeks ago by gk (previous) (diff)

comment:8 Changed 5 weeks ago by sysrqb

Status: reopenedneeds_review

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.

comment:9 in reply to:  8 Changed 5 weeks ago by nobell

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.

comment:10 in reply to:  8 Changed 5 weeks ago by gk

Resolution: fixed
Status: needs_reviewclosed

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).

comment:11 Changed 3 weeks ago by gaba

Keywords: user-feedback blog added

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

Note: See TracTickets for help on using tickets.