#27232 closed defect (duplicate)

Updater redowloads and reinstalls update again

Reported by: sysrqb Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff60-esr
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

After updating to 8.0a10 (and restarting), Tor Browser then redownloads the update and shows an indicator for restarting the browser and installing it. After restarting, this happens again.

[08-21 02:09:13] Torbutton INFO: tor SOCKS: https://aus1.torproject.org/torbrowser/update_3/alpha/Linux_x86_64-gcc3/8.0a9/en-US via

Child Tickets

Change History (5)

comment:1 Changed 13 months ago by sysrqb

I think this is because the update URL is formatted here:

  async formatUpdateURL(url) {
    const locale = await this.getLocale();

    return url.replace(/%(\w+)%/g, (match, name) => {
      switch (name) {
        case "PRODUCT":
          return Services.appinfo.name;
        case "VERSION":
#ifdef TOR_BROWSER_UPDATE
          return TOR_BROWSER_VERSION;                                                                                                                                                                              
#else
          return Services.appinfo.version;
#endif

app.update.url is: https://aus1.torproject.org/torbrowser/update_3/%CHANNEL%/%BUILD_TARGET%/%VERSION%/%LOCALE%

Looking at the update url: https://aus1.torproject.org/torbrowser/update_3/alpha/Linux_x86_64-gcc3/8.0a9/en-US

%VERSION% is compile-time hard-coded as the original version number. I think we want the torbrowser.version pref?

comment:2 in reply to:  1 ; Changed 13 months ago by mcs

Replying to sysrqb:

...
%VERSION% is compile-time hard-coded as the original version number. I think we want the torbrowser.version pref?

The torbrowser.version value should be the same as the compile time define TOR_BROWSER_VERSION. We had to define TOR_BROWSER_VERSION because there are some places in the update code where we cannot access the prefs (at least that is what I remember). In any case, after the browser is updated to 8.0a10, %VERSION% should be formatted using the new version number. Or am I missing something?

This is a dumb question, but are you sure the update succeeded? With one of my copies of 8.0a9 on macOS, the update does not want to apply. I am not yet sure why not though.

comment:3 in reply to:  2 Changed 13 months ago by sysrqb

Replying to mcs:

Replying to sysrqb:

...
%VERSION% is compile-time hard-coded as the original version number. I think we want the torbrowser.version pref?

The torbrowser.version value should be the same as the compile time define TOR_BROWSER_VERSION. We had to define TOR_BROWSER_VERSION because there are some places in the update code where we cannot access the prefs (at least that is what I remember). In any case, after the browser is updated to 8.0a10, %VERSION% should be formatted using the new version number. Or am I missing something?

Nope, that sure does make sense.

This is a dumb question, but are you sure the update succeeded? With one of my copies of 8.0a9 on macOS, the update does not want to apply. I am not yet sure why not though.

After restarting, torbrowser.version is set a 8.0a10, and I also have the new about:tor (and onboarding), so the update did apply. So I'm not sure what's going on here.

comment:4 Changed 13 months ago by sysrqb

Something else I should note. After updating:

browser.startup.homepage_override.torbrowser.version and extensions.lastTorBrowserVersion are both 8.0a9

while

extensions.torbutton.lastBrowserVersion and torbrowser.version are 8.0a10.

On my TB 7.5 installation, I see all four of these are currently 7.5.6.

comment:5 Changed 13 months ago by gk

Resolution: duplicate
Status: newclosed

Duplicate of #27221. Note that, surprisingly, does not happen with an update from a new 8.0a9 to 8.0a10.

Note: See TracTickets for help on using tickets.