notify users that update is downloading
An important improvement that was discussed in #25694 (moved) 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.
Activity
Trac:
Parent Ticket: #25694 (moved)
Trac:
Parent: N/A to #25694 (moved)-
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
The bug28885-01 branch within the brade repo also contains the patch for #27828 (moved); that patch and the patches for this ticket are related; it probably makes sense to review and test them together.
Trac:
Keywords: N/A deleted, TorBrowserTeam201901R added
Status: new to needs_review 
Here is what I got so far:
-
I wonder whether we should use a different icon for the download (like an arrow down) as we have the arrow up associaed with update 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.
-
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.)
-
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.Trac:
Keywords: TorBrowserTeam201901R deleted, TorBrowserTeam201901 added
Status: needs_review to needs_revision-
-
Replying to gk:
Here is what I got so far:
- I wonder whether we should use a different icon for the download (like an arrow down) as we have the arrow up associaed with update 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 BrowserKathy 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 (moved), 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.
- 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.
- 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!
-
Replying to mcs:
Replying to gk:
Here is what I got so far:
- I wonder whether we should use a different icon for the download (like an arrow down) as we have the arrow up associaed with update 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 (moved), 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.
- 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.
-
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:
- 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).
- 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.
-
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:
- 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.
- 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.
-
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 (moved)
-
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 (moved) since we tested these fixes together.
Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam201901 deleted, TorBrowserTeam201901R added -
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 (moved) 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.
Trac:
Keywords: TorBrowserTeam201902R deleted, TorBrowserTeam201902 added
Status: needs_review to needs_revision -
Good catch. Here is a new patch: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug28885-03&id=d176b2c555c1f0298ab8764bcb6c4fda8dc255ff
Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam201902 deleted, TorBrowserTeam201902R added mentioned in issue #29180 (moved)
