Opened 6 months ago

Closed 4 months ago

#28885 closed defect (fixed)

notify users that update is downloading

Reported by: mcs Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team, TorBrowserTeam201902R, tbb-update
Cc: tbb-team, antonela Actual Points:
Parent ID: #25694 Points:
Reviewer: Sponsor:

Description

An important improvement that was discussed in #25694 is to let users know when an update is in the process of being downloaded. Firefox does not show this information in an obvious way; users need to open about:preferences and look in the Updates section or open the about box. Tor Browser users are sometimes confused because they know an update is available but have no easy way to know if it is being downloaded, and downloading the MAR files can take a while over Tor.

We plan to add a new "Downloading Tor Browser update..." message that will be displayed in the hamburger menu. We will also ensure that the standard "update" icon is displayed on the hamburger menu toolbar icon so users know to look inside for more info.

Child Tickets

Change History (16)

comment:1 Changed 6 months ago by mcs

Parent ID: #25694

comment:2 Changed 5 months ago by mcs

Keywords: TorBrowserTeam201901R added
Status: newneeds_review

This is now ready for review. There is one torbutton patch (to add one localizable string) and a tor-browser patch:
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug28885-01&id=03e00bd1ea4cc090bd27cc56b994bed66074f628

https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug28885-01&id=7e8adb1d6405da97866ea6dea8875eb8455aafff

The bug28885-01 branch within the brade repo also contains the patch for #27828; that patch and the patches for this ticket are related; it probably makes sense to review and test them together.

comment:3 Changed 5 months ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201901R removed
Status: needs_reviewneeds_revision

Here is what I got so far:

1) I wonder whether we should use a different icon for the download (like an arrow *down*) as we have
the arrow up associaed with *up*date is ready to get applied and this is the general Firefox meaning of that icon. I am a bit worried that we set user expectations wrong here one can't discriminate between the download and ready-to-apply state at a glance.

2) If one has the about dialog open while a download is happening, closes it, opens the hamburger menu and clicks on menuitem then the download stops. I guess this is unexpected and should get fixed?
(Interestingly enough, after clicking the about dialog in that scenario and opening it again shows 0 of XX MB at the beginning. It jumps to the already download amount (and goes from there) later on when the download is resumed. It seems showing "0" in this case is wrong.)

3) 15:34 <+GeKo> you do
15:34 <+GeKo> this.showUpdateDownloadingNotification(update, false);
15:34 <+GeKo> but only have
15:34 <+GeKo> showUpdateDownloadingNotification()
15:34 <+GeKo> without any arguments
15:35 <+GeKo> is that a copy and paste error?

I applied the Torbutton patch to master (commit 15c369f661fd360c9715b4dd7da147f7aa8f2443), though, to give more time to translators.

comment:4 Changed 5 months ago by pili

Cc: antonela added
Keywords: ux-team added

comment:5 in reply to:  3 ; Changed 5 months ago by mcs

Replying to gk:

Here is what I got so far:

1) I wonder whether we should use a different icon for the download (like an arrow *down*) as we have
the arrow up associaed with *up*date is ready to get applied and this is the general Firefox meaning of that icon. I am a bit worried that we set user expectations wrong here one can't discriminate between the download and ready-to-apply state at a glance.

We opted to use the same icon because Mozilla uses the same upward arrow icon for all updater-related messages, i.e.,

  Download Tor Browser update            // Shown if automatic updates are disabled
  Download a fresh copy of Tor Browser   // shown if the update fails
  Restart to update Tor Browser

Kathy and I don't have strong feelings about using one icon or two, although we have not looked at how difficult it would be to use more than one. In some of explorations Antonela did in #25694, the design did include a different icon for restart as well. Kathy and I would like to minimize changes we make so as to avoid diverging from Firefox too much.

2) If one has the about dialog open while a download is happening, closes it, opens the hamburger menu and clicks on menuitem then the download stops. I guess this is unexpected and should get fixed?
(Interestingly enough, after clicking the about dialog in that scenario and opening it again shows 0 of XX MB at the beginning. It jumps to the already download amount (and goes from there) later on when the download is resumed. It seems showing "0" in this case is wrong.)

Kathy and I will try to reproduce this bug. Does clicking the "Downloading..." menu item open the about dialog like it is supposed to (at which point the download stops)? By "stops" do you mean "stops making progress" or do you mean the download is completely canceled?

Showing 0MB when resuming a download is probably not something we introduced but we could look into it. When the about dialog or large update dialog is opened (i.e., via "Check for Tor Browser update"), Mozilla stops and restarts the download. This may be the root cause of some of the problems you saw. They used to download MAR files slowly when no UI was visible, which is the origin of the stop and restart behavior. I am not sure if we can easily eliminate that code though.

3) 15:34 <+GeKo> you do
15:34 <+GeKo> this.showUpdateDownloadingNotification(update, false);
15:34 <+GeKo> but only have
15:34 <+GeKo> showUpdateDownloadingNotification()
15:34 <+GeKo> without any arguments
15:35 <+GeKo> is that a copy and paste error?

That is an easy one and we will fix it.

I applied the Torbutton patch to master (commit 15c369f661fd360c9715b4dd7da147f7aa8f2443), though, to give more time to translators.

Good plan, and thanks!

comment:6 in reply to:  5 ; Changed 5 months ago by gk

Replying to mcs:

Replying to gk:

Here is what I got so far:

1) I wonder whether we should use a different icon for the download (like an arrow *down*) as we have
the arrow up associaed with *up*date is ready to get applied and this is the general Firefox meaning of that icon. I am a bit worried that we set user expectations wrong here one can't discriminate between the download and ready-to-apply state at a glance.

We opted to use the same icon because Mozilla uses the same upward arrow icon for all updater-related messages, i.e.,

  Download Tor Browser update            // Shown if automatic updates are disabled
  Download a fresh copy of Tor Browser   // shown if the update fails
  Restart to update Tor Browser

Kathy and I don't have strong feelings about using one icon or two, although we have not looked at how difficult it would be to use more than one. In some of explorations Antonela did in #25694, the design did include a different icon for restart as well. Kathy and I would like to minimize changes we make so as to avoid diverging from Firefox too much.

Okay. Not needed for this bug anyway, just something I was wondering while testing.

2) If one has the about dialog open while a download is happening, closes it, opens the hamburger menu and clicks on menuitem then the download stops. I guess this is unexpected and should get fixed?
(Interestingly enough, after clicking the about dialog in that scenario and opening it again shows 0 of XX MB at the beginning. It jumps to the already download amount (and goes from there) later on when the download is resumed. It seems showing "0" in this case is wrong.)

Kathy and I will try to reproduce this bug. Does clicking the "Downloading..." menu item open the about dialog like it is supposed to (at which point the download stops)? By "stops" do you mean "stops making progress" or do you mean the download is completely canceled?

Yes, it opens the dialog. It's not canceled in the way that one has to start over again but it suddenly stops making progress (and the icon on the hamburger menu + the menuitem vanish).

Showing 0MB when resuming a download is probably not something we introduced but we could look into it. When the about dialog or large update dialog is opened (i.e., via "Check for Tor Browser update"), Mozilla stops and restarts the download. This may be the root cause of some of the problems you saw. They used to download MAR files slowly when no UI was visible, which is the origin of the stop and restart behavior. I am not sure if we can easily eliminate that code though.

Okay, thanks for the explanation. It's been confusing that trying to get more information about the download progress by clicking on that item suddenly stops this progress. And it is not resuming automatically once the dialog closes or something. One has to re-trigger the update process to get it going again.

comment:7 in reply to:  6 ; Changed 5 months ago by mcs

Replying to gk:

Yes, it opens the dialog. It's not canceled in the way that one has to start over again but it suddenly stops making progress (and the icon on the hamburger menu + the menuitem vanish).

So far Kathy and I have not been able to reproduce this using a debug build on Linux or macOS. We will try again with an optimized build. Two more questions for you:

  1. Can you reproduce the problem if you open the about dialog a second time without using the new hamburger menu item? If so, that might imply this is not a new bug (it is much more noticeable with the new "Downloading..." hamburger menu item though).
  2. Does the download restart on its own if you wait a while? We see a pause but it does restart within 5-10 seconds. This behavior is confusing though.

comment:8 in reply to:  7 ; Changed 5 months ago by gk

Replying to mcs:

Replying to gk:

Yes, it opens the dialog. It's not canceled in the way that one has to start over again but it suddenly stops making progress (and the icon on the hamburger menu + the menuitem vanish).

So far Kathy and I have not been able to reproduce this using a debug build on Linux or macOS. We will try again with an optimized build. Two more questions for you:

  1. Can you reproduce the problem if you open the about dialog a second time without using the new hamburger menu item? If so, that might imply this is not a new bug (it is much more noticeable with the new "Downloading..." hamburger menu item though).

Yes.

  1. Does the download restart on its own if you wait a while? We see a pause but it does restart within 5-10 seconds. This behavior is confusing though.

No, it does not. It is just saying "Downloading update" and the throbber spins but nothing happens.

I am using a patched 8.5a5 (I essentially applied your patch "by hand" to the various pieces in the omni.ja's) to test the update to 8.5a6 on a Linux machine.

comment:9 in reply to:  8 Changed 5 months ago by mcs

Replying to gk:

I am using a patched 8.5a5 (I essentially applied your patch "by hand" to the various pieces in the omni.ja's) to test the update to 8.5a6 on a Linux machine.

Kathy and I were finally able to reproduce this. I opened a new ticket: #29180

comment:10 Changed 5 months ago by mcs

Keywords: TorBrowserTeam201901R added; TorBrowserTeam201901 removed
Status: needs_revisionneeds_review

An updated patch is available here:
https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug28885-02&id=2a43d0676e0b1c39e8620bf0697ca9c2d5247ded

The bug28885-02 branch also contains a fix for #29180 since we tested these fixes together.

comment:11 Changed 5 months ago by gk

Keywords: tbb-updater added

comment:12 Changed 5 months ago by gk

Keywords: TorBrowserTeam201902R added; TorBrowserTeam201901R removed

Moving our review tickets to February.

comment:13 Changed 5 months ago by gk

Keywords: tbb-update added; tbb-updater removed

Renaming keyword to make it a bit broader

comment:14 in reply to:  10 Changed 4 months ago by gk

Keywords: TorBrowserTeam201902 added; TorBrowserTeam201902R removed
Status: needs_reviewneeds_revision

Replying to mcs:

An updated patch is available here:
https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug28885-02&id=2a43d0676e0b1c39e8620bf0697ca9c2d5247ded

The bug28885-02 branch also contains a fix for #29180 since we tested these fixes together.

Thanks, this looks good to me. Just a final nit (sorry for not mentioning that one earlier). Please avoid mixing bracing and non-bracing style within loops etc.:

+      for (let i = 0; i < elements.length; ++i) {
+        let elem = elements.item(i);
+        if (elem.hasAttribute(attrName))
+          elem.setAttribute(attrName, label);
+      }

Just braces around the if-clause and we are good to go.

comment:15 Changed 4 months ago by mcs

Keywords: TorBrowserTeam201902R added; TorBrowserTeam201902 removed
Status: needs_revisionneeds_review

comment:16 Changed 4 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Thanks! Merged to tor-browser-60.5.0esr-8.5-1 (commit d176b2c555c1f0298ab8764bcb6c4fda8dc255ff).

Note: See TracTickets for help on using tickets.