Opened 2 years ago

Closed 2 years ago

#18170 closed defect (fixed)

After an update to Tor Browser 5.5 only changelog tab is shown

Reported by: gk Owned by: mcs
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201602R tbb-5.5-regression
Cc: mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by gk)

On my Windows 7 test machine there is only the changelog tab shown after an upgrade from 5.0.7. No about:tor tab is visible as it should probably be.

Child Tickets

Change History (12)

comment:1 Changed 2 years ago by gk

Description: modified (diff)
Summary: After update to Tor Browser 5.5 only changelog tab is shownAfter an update to Tor Browser 5.5 only changelog tab is shown

comment:2 Changed 2 years ago by bugzilla

Same with 5.5a6 -> 6.0a1

comment:3 Changed 2 years ago by gk

I think this would give us a fix for #18174 (or the special case of #16725 where about:tbupdate plays the homepage roll for a session), too.

comment:4 Changed 2 years ago by gk

Keywords: TorBrowserTeam201602 added

comment:5 Changed 2 years ago by gk

Keywords: tbb-5.5-regression added

comment:6 Changed 2 years ago by mcs

Kathy and I reproduced this bug today and spent a little time debugging it. It seems that when staged updates are not used, about:tor is not opened. Of course staged updates are supposed to be used by default, but on Windows everything appears to get staged and then, upon restart, the staged files seem to be ignored in favor or re-applying the update from the mar file. So there may actually be two bugs:

  1. When staging is not used, about:tor is not opened. You can reproduce this on non-Windows platforms by setting app.update.staging.enabled = false before starting an update.
  2. Staging is not occurring correctly on Windows. This makes updates take longer.

We will continue to debug.

comment:7 Changed 2 years ago by mcs

Here is a fix for the first part:
https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug18170-01&id=b6c905e86ea9786fdbd9676d6cc057e71cd2f6a9
This is probably a candidate for upstreaming to Mozilla, but let's make sure it works for Tor Browser first.

Next we will work on the Windows-specific problem of staging not being used when it should be.

comment:8 Changed 2 years ago by mcs

Keywords: TorBrowserTeam201602R added; TorBrowserTeam201602 removed
Status: newneeds_review

I created #18292 to cover the Windows-specific problem. Please review the patch mentioned in comment:7.

comment:9 in reply to:  7 ; Changed 2 years ago by gk

Status: needs_reviewneeds_information

Replying to mcs:

Here is a fix for the first part:
https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug18170-01&id=b6c905e86ea9786fdbd9676d6cc057e71cd2f6a9
This is probably a candidate for upstreaming to Mozilla, but let's make sure it works for Tor Browser first.

I wonder whether the defense-in-depth-part is actually just that. Isn't it the case that users coming from Tor Browser < 5.5.3 would need it given the other fixes aren't in (for instance) 5.5.2 and the latter is causing the restart and the observer notifications?

comment:10 in reply to:  9 Changed 2 years ago by mcs

Replying to gk:

I wonder whether the defense-in-depth-part is actually just that. Isn't it the case that users coming from Tor Browser < 5.5.3 would need it given the other fixes aren't in (for instance) 5.5.2 and the latter is causing the restart and the observer notifications?

You are right. I think we should keep the entire patch but change the check in comment. Here is my proposal:

Bug 18170: After update, only changelog tab shown

When in permanent private browsing mode, always return false
for isAutomaticRestoreEnabled. This ensures that there will
not be any confusion inside nsBrowserContentHandler.defaultArgs
as to whether a one time session restore will occur.

Also, for consistency and in case someone looks at the pref,
avoid setting browser.sessionstore.resume_session = true during
browser shutdown.

This bug occurred when staging was not used during the update
process. On Windows it always occurred because staging is not
used even when it should be (see #18292).

comment:11 Changed 2 years ago by gk

Keywords: TorBrowserTeam201602 added; TorBrowserTeam201602R removed
Owner: changed from tbb-team to mcs
Status: needs_informationassigned

Looks good to me. Could you make a new commit with the adapted commit message?

comment:12 Changed 2 years ago by gk

Keywords: TorBrowserTeam201602R added; TorBrowserTeam201602 removed
Resolution: fixed
Status: assignedclosed

I realized that we can save one roundtrip by me just amending the commit(s) which I did: 7c8b836e87bc2e5251ff085d48114d61678544d3 on tor-browser-38.6.1esr-6.0-1 and 17015208f6a990a22a89980bf495618009cf1ef8 on tor-browser-38.6.1esr-5.5-1, thanks.

Note: See TracTickets for help on using tickets.