av9ash/GitBugs huggingface dataset:
Bug: Undo Close Tab reopens the tab and presses "back" instead of staying in the correct page
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-04-04 06:36:10+00:00
Resolved: 2020-06-29 11:43:48+00:00

Using Firefox Nightly.
mozregression says it started happening in this range of the 2020-03-10 nightly build:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3004bc7597a088e181fbcb9a9044b8d952e9d45f&tochange=5b47cfcab1554c89400b7a6299ff0cabac4bda0c

Steps to reproduce:
1) Open a new tab.
2) Visit google.com
3) Search for something.
4) Close tab.
5) Press Ctrl+Shift+T (on Linux)

Result:
The tab will reopen. The location bar will briefly show the correct URL with the search query, but will then switch back to google.com and show that page.

Expected result:
The tab should reopen on the search query result.

I couldn't manage to reproduce it with a brand new profile, but it happens in several other profiles I use, one of them with no settings changes, created in the past few weeks.
Bug: PDF: Some Korean letters are copied incorrectly
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-04-04 08:56:29+00:00
Resolved: 2022-01-05 16:18:16+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Open this PDF file in FireFox.
https://gongu.copyright.or.kr/gongu/wrt/cmmn/wrtFileDownload.do?wrtSn=9002094&fileSn=1&wrtFileTy=01

If the direct download link does not work, go to https://gongu.copyright.or.kr/gongu/wrt/wrt/view.do?wrtSn=9002094&menuNo=200030
 and click the big teal download button at the centre of the page.

Select the first sentence, and right click it.


Actual results:

"새쵨하게 흐린 펈이 눈이 씬 듯하더니 눈은 아니 씤고 얼다가 만 비가 추윁추윁 내리는 꾠이었다." is copied. See the attached screenshot. Top is FireFox, and bottom is Chrome.


Expected results:

"새침하게 흐린 품이 눈이 올 듯하더니 눈은 아니 오고 얼다가 만 비가 추
적추적 내리는 날이었다." should be copied, as is when doing the same thing in Chrome.
Bug: Closed tabs menu does not contain all closed tabs in a Firefox window (due to sessionstore.max_tabs_undo)
Status: NEW
Priority: P3
Created: 2020-04-04 11:15:12+00:00
Resolved: 2023-10-05 13:57:49+00:00

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

While right clicking on a tab, by accident instead of selecting "close tabs on the right" I selected "close all other tabs" and by accident again I clicked on "okay" when I was prompted "do you want to close 42 tabs?".
So I went into history menu, "tabs closed recently" but there were not 42 tabs, just ~20+ tabs

OS: Fedora 31
Bug: pdf download forces multiple tabs
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-04 13:16:18+00:00
Resolved: 2020-04-06 16:02:27+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Clicked a link to download a pdf document.


Actual results:

Multiple tabs are opened infinitely until something crashes.


Expected results:

pdf file downloads
Bug: Firefox 74.0.1 (64-bit) Missing Menus and Keyboard Shortcuts not Functioning
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-04 18:25:32+00:00
Resolved: 2020-04-08 08:08:32+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Opened Firefox from Mac dock. Opened Firefox windows from e-mail links.
Running Firefox 74.0.1 on OS X Catalina 10.15.4


Actual results:

No app menus appear; Forward/Back button hover tooltips are missing. Keyboard shortcuts such as Cmd-D and Cmd-W won't work. Right-click context menu is unreadable - displays missing text items.


Expected results:

Firefox app and context menus should always be visible. Keyboard shortcuts should function.
Bug: After a while Twitter website stops updating after upgrade to Firefox 74.0.1
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-04 19:34:55+00:00
Resolved: 2020-04-13 12:00:22+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

I log into Twitter in Firefox 74.0.1 and keep the Twitter tab open for a short while. After 30 to 60 minutes the Twitter website stops loading properly. This bug did not happen in Firefox 74.0.0. 


Actual results:

Twitter website stops updating properly and only way to fix this is to restart Firefox.


Expected results:

Twitter website should update when pressed refresh button or automagically when Twitter browser window or a twitter tab is open.
Bug: ugly bat-like evil looking creatures
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-04 19:40:44+00:00
Resolved: 2020-04-06 18:01:05+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

customize firefox


Actual results:

i saw an ugly bat-like evil looking creature


Expected results:

i should be able to customize firefox (or go to a website that doesn't exist) without seeing evil looking creatures
Bug: Default Search Engine list was wiped after update to 74.0.1
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-04-04 22:09:12+00:00
Resolved: 2020-04-23 11:44:37+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Type in any search term (i.e "github actions")


Actual results:

Went to github.com


Expected results:

Should have searched on Google for "github actions"
Bug: Slow File Upload with Firefox
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-05 05:51:16+00:00
Resolved: 2020-04-07 22:23:36+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36

Steps to reproduce:

1. Go to YouTube Creator.
2. Upload button.
3. Drag a 5-10GB video file to upload box.
4. Speed is half of other browsers


Actual results:

The upload speed is 200Mbps compare to Chrome or Edge runs at 500Mbps (current max speed).


Expected results:

Should be same at full speed upload.
Bug: Showing top site items/Recently visited items in Private Mode is inconsistent in Address Bar
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-04-05 07:08:02+00:00
Resolved: 2020-07-10 06:19:01+00:00

Nightly 76.0a1 (2020-04-04)
macOS 10.15.4

STR:
1.) Open a Private Window
2.) Visit a page
3.) Focus the Address Bar

Result: No Top site items/No Recently visited items are shown in Address Bar (probabaly okay, because this is an Private Mode Window)

4.) But now clear the Address Bar

Result: Top SItes items/Recently visited items are shown in Address Bar

Not sure if this is intended. But this feels inconsistent. Maybe they shouldn't be shown at all in Private Mode or show them also when focussing the Address Bar.

Thanks.
Bug: Pressing Enter in Urlbar opens new Tab instead of using the current one.
Status: NEW
Priority: P5
Created: 2020-04-05 07:42:01+00:00
Resolved: 2020-07-10 06:19:39+00:00

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

This might be a Linux only issue.

1. Open Firefox and browse to example.com
2. Switch keyboard layout to the neo-layout (https://neo-layout.org/):
   setxkbmap de neo
   Attention: This layout is completely different from QWERTY,
   so prepare "setxkbmap us" beforehand or use the website to lookup the keys.
3. Select the URLBar and hit: AltGr+v
   AltGr+v is a shortcut for the Enter key in neo-layout.
   To be more precise the v key on ISO_LEVEL_5 is the Enter key.


Actual results:

A new Tab was opened.
(Similar to pressing AltGr+Enter on a QWERTY layout.)


Expected results:

The website should have been opened in the same Tab.

I assume that following Bugs are related:
https://bugzilla.mozilla.org/show_bug.cgi?id=1389739 - ALTGR+Enter opens a canonized URL rather than opening in a new tab
https://bugzilla.mozilla.org/show_bug.cgi?id=1391239 - pressing AltGr-Enter in the search bar should open page in a new tab
Bug: OSX Power Impact
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-05 14:14:07+00:00
Resolved: 2020-04-09 14:00:10+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

Steps to reproduce:

Open www.bbc.co.uk/news and scroll up and down the page, this is the same for all websites


Actual results:

OS power impact 140+, battery lift drops off a cliff, laptop gets hot after 20/30 minutes use


Expected results:

The opposite of the above :)
Bug: After connecting to VPN Firefox is unable to navigate to sites inside the VPN but Chrome can
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-04-05 15:07:09+00:00
Resolved: 2020-04-27 06:38:54+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Add any vpn addon and start browsing
You won't be able to browse (No internet)
Turned off vpn (Internet starts working)

(This issue is specifically for windows operating system)


Actual results:

Internet stops working on connecting with vpn addon


Expected results:

Internet should work on connecting with vpn addon
Bug: 6.57 - 31.91% about_newtab_with_snippets (linux64-*, macosx1014-64-shippable, windows10-64-*, windows7-32-shippable) regression on push 7a21216d200a80d14e6a4ccd2008f6404d3c79dd (Thu April 2)
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-04-05 22:35:33+00:00
Resolved: 2020-04-09 22:00:04+00:00

6.57 - 31.91% about_newtab_with_snippets (linux64-shippable, linux64-shippable-qr, macosx1014-64-shippable, windows10-64-shippable, windows10-64-shippable-qr, windows7-32-shippable) regression on push 7a21216d200a80d14e6a4ccd2008f6404d3c79dd (Thu April 2 2020)


Talos has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=7a21216d200a80d14e6a4ccd2008f6404d3c79dd

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

  32%  about_newtab_with_snippets macosx1014-64-shippable opt e10s stylo       70.54 -> 93.05
  30%  about_newtab_with_snippets macosx1014-64-shippable opt e10s stylo       70.56 -> 91.62
  12%  about_newtab_with_snippets linux64-shippable opt e10s stylo             69.54 -> 77.72
   9%  about_newtab_with_snippets linux64-shippable-qr opt e10s stylo          71.77 -> 78.38
   8%  about_newtab_with_snippets windows10-64-shippable-qr opt e10s stylo     60.64 -> 65.73
   7%  about_newtab_with_snippets windows10-64-shippable opt e10s stylo        60.83 -> 65.37
   7%  about_newtab_with_snippets windows7-32-shippable opt e10s stylo         59.27 -> 63.17


You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=25539

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the Talos jobs in a pushlog format.

To learn more about the regressing test(s), please see: https://wiki.mozilla.org/TestEngineering/Performance/Talos

For information on reproducing and debugging the regression, either on try or locally, see: https://wiki.mozilla.org/TestEngineering/Performance/Talos/Running

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations: https://wiki.mozilla.org/TestEngineering/Performance/Talos/RegressionBugsHandling
Bug: Private window saves my logins
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-06 02:22:23+00:00
Resolved: 2020-04-20 16:12:48+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

1. Open private window
2. Log into service (I tried GitHub and Facebook).
3. Close private window
4. Open a new private window
5. Visit GitHub or Facebook, see that you are logged in


Actual results:

A fresh private window actually stored my login credentials already (in cookie form?)


Expected results:

I expected a new private window to be totally fresh: no state whatsoever. So I expected these websites to show me as not signed-in, when opening a new private window to them.
Bug: Enabled HTTP/3 support via about:config, found some sites unreachable, disabled it, same sites still randomly unreachable.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-06 02:34:21+00:00
Resolved: 2020-05-14 18:57:47+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

step1: enable http3 via about:config
step2: go to ex: https://geekflare.com/http3-test/
Should work for a while, but after a bit will stop working, just loads forever.
about:networking shows that its connected via http3.
step4: disable http3, restart firefox
step5: go to site again, still unreacahable, about:networking shows that its trying to connect via http3 still.
I launched firefox with a new(ish...it was before I started monkeying around with http3 anyway) profile, and the site(s) that weren't working before worked...about:networking also showed they were connecting via http2.
Bug: The “Alerts” option is not displayed in “Sort by:” dropdown after syncing logins without refreshing the page if previously no breached/vulnerable were saved
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-04-06 09:53:37+00:00
Resolved: 2020-04-16 08:22:25+00:00

[Affected versions]:
- Nightly 76.0a1 (Build ID: 20200405212522)

[Affected Platforms]:
- Windows 10 x64
- Mac 10.14.6
- Ubuntu 18.04 x64

[Prerequisites]:
- No vulnerable/breached accounts are displayed in the login list.
- Have a Firefox Account with saved logins in which at least one is vulnerable and one is breached.

[Steps to reproduce]:
1. Open the Firefox browser with the profile from prerequisites.
2. Navigate to the “about:logins” page.
3. Sign in to Sync with the Firefox Account from prerequisites.
4. Click on the “Sort by:” button.
5. Observe the dropdown menu.

[Expected result]:
- The “Alerts” option is displayed on the dropdown.

[Actual result]:
- The “Alerts” option is not displayed on the dropdown.

[Regression]
-  The issue is not reproducible with older Nightly 76.0a1 builds. Considering this, using the mozregression tool I have found the issue that broke this in the latest Nightly build. Here are the results:
 - Pushlog: https://tinyurl.com/ss3vbj6.
 - Last good revision: 6e570f08779fae0699aec929011f3e0f8d668c33.
 - First bad revision: 4f97d7e79d15a71b12d268e1eb3967a79c3adaa9.

From this pushlog it seems that Bug 1626413 introduced this behavior.

[Notes]:
- The “Alerts” option is displayed after refreshing the page.
- This issue is not reproducible if I have breached/vulnerable logins saved in the profile before signing in to Sync.
- Attached a screen recording with the issue.
Bug: Private window clear popup cookie
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-04-06 13:56:02+00:00
Resolved: 2020-04-27 10:54:39+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

Steps to reproduce:

1 - Open a website (that use cookies) in private window;
2 - Access a popup window of this web site;
3 - Close website, verifying the cookies in popup were cleaned;


Actual results:

Only in private window, firefox lost cookies of popup when close parent window.


Expected results:

Cookies in the popup shouldn't be cleared.
Bug: Resizing the browser to min-width resets the search bar width after restoring the window to normal size, making the spacer next to it wider than usual
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-06 13:57:17+00:00
Resolved: 2020-05-11 08:59:52+00:00

STR:
1. Latest Nightly
2. Add search bar to the toolbar
3. Drag the resizer between the urlbar and the search bar in a way that the spacers to the left and right do not get smaller or bigger
4. Resize the browser window width to the smallest possible
5. Restore the window to normal

AR:
1. The search bar's width gets reset
2. The spacer after the search bar gets wider than usual

ER:
1. The previously customized search bar's width is retained
2. The spacer after the search bar is at normal width
Bug: Intermittent browser/base/content/test/protectionsUI/browser_protectionsUI_trackers_subview.js | We have 2 trackers in the list - Got 1, expected 2
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-04-06 14:27:12+00:00
Resolved: 2021-04-06 17:01:03+00:00

**Filed by:** nbeleuzu [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer.html#?job_id=296419128&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ZZVIdANyScySw2_-VKj1Cw/runs/0/artifacts/public/logs/live_backing.log

---

[task 2020-04-06T13:11:16.119Z] 13:11:16     INFO - TEST-PASS | browser/base/content/test/protectionsUI/browser_protectionsUI_trackers_subview.js | Trackers view was shown - 
[task 2020-04-06T13:11:16.119Z] 13:11:16     INFO - Buffered messages finished
[task 2020-04-06T13:11:16.122Z] 13:11:16     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/protectionsUI/browser_protectionsUI_trackers_subview.js | We have 2 trackers in the list - Got 1, expected 2
[task 2020-04-06T13:11:16.122Z] 13:11:16     INFO - Stack trace:
[task 2020-04-06T13:11:16.123Z] 13:11:16     INFO - chrome://mochikit/content/browser-test.js:test_is:1320
[task 2020-04-06T13:11:16.123Z] 13:11:16     INFO - chrome://mochitests/content/browser/browser/base/content/test/protectionsUI/browser_protectionsUI_trackers_subview.js:assertSitesListed:82
[task 2020-04-06T13:11:16.124Z] 13:11:16     INFO - chrome://mochitests/content/browser/browser/base/content/test/protectionsUI/browser_protectionsUI_trackers_subview.js:testTrackersSubView:111
[task 2020-04-06T13:11:16.124Z] 13:11:16     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1062
[task 2020-04-06T13:11:16.125Z] 13:11:16     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1097
[task 2020-04-06T13:11:16.125Z] 13:11:16     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:925
[task 2020-04-06T13:11:16.126Z] 13:11:16     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:918
[task 2020-04-06T13:11:16.129Z] 13:11:16     INFO - TEST-PASS | browser/base/content/test/protectionsUI/browser_protectionsUI_trackers_subview.js | Has an item for trackertest.org - 
[task 2020-04-06T13:11:16.130Z] 13:11:16     INFO - TEST-PASS | browser/base/content/test/protectionsUI/browser_protectionsUI_trackers_subview.js | List item is visible - 
[task 2020-04-06T13:11:16.130Z] 13:11:16     INFO - TEST-PASS | browser/base/content/test/protectionsUI/browser_protectionsUI_trackers_subview.js | Indicates whether the tracker was blocked or allowed - 
[task 2020-04-06T13:11:16.131Z] 13:11:16     INFO - Not taking screenshot here: see the one that was previously logged
Bug: The "Created" timestamp is wrongly updated for the logins saved/created when logged into FxA then synced on other profile
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-06 14:29:15+00:00
Resolved: 2020-04-29 19:23:09+00:00

[Affected versions]:
- Nightly 76.0a1 (Build ID: 20200406092400)

[Affected Platforms]:
- Windows 10 x64
- Mac 10.14.6
- Unbuntu 18.04 x64

[Prerequisites]:
- Be logged to FxA account.

[Steps to reproduce]:
1. Open the Firefox browser with the profile from prerequisites.
2. Navigate to "about:logins" page and create a new login.
3. Go to the profile's directory and open logins.json.
4. Change the "timeCreated", "timeLastUsed" and "timePasswordChanged" values of the created login to "1338544168000".
5. Restart the browser and observe that the "Created" section is updated to June 1, 2012.
6. Click the "Firefox Account" toolbar button and click the "Sync Now" option.
7. Close the Firefox profile.
8. Create and open a new Firefox profile.
9. Navigate to "about:logins" and sync logins.
10. Observe the login created in step 2.

[Expected result]:
- The "Created" and "Last used" timestamp remains set to June 1, 2012.

[Actual result]:
- The "Created" and "Last used" timestamp is updated with the current date.

[Notes]:
- This issue affects the breached accounts since their create date is updated after syncing logins on other profiles. The breached accounts will no longer be marked as breached.
- One strange thing that I have noticed is that if you create an account when you are not logged to FxA, then you log in to FxA, sync logins then even if you sync them on other Firefox profiles the "Created" and "Last used" timestamp is not updated for them. 
- I need to investigate more if this is also reproducible on Firefox 75 and 74 and if it's a regression. 
- Attached a screen recording with the issue.
Bug: Cannot delete wrong entries from address bar autocomplete
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-06 14:33:11+00:00
Resolved: 2020-04-08 08:57:58+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

Steps to reproduce:

Type a wrong address into the address bar. When you start typing the correct address, Firefox now autocompletes using the wrong one. There is no way to delete it. Delete does not work, shift + delete does not work. Yes, I am highlighting the entry with the arrow keys first.


Actual results:

Type a wrong address into the address bar. When you start typing the correct address, Firefox now autocompletes using the wrong one. There is no way to delete it. Delete does not work, shift + delete does not work. Yes, I am highlighting the entry with the arrow keys first.


Expected results:

Type a wrong address into the address bar. When you start typing the correct address, Firefox now autocompletes using the wrong one. There is no way to delete it. Delete does not work, shift + delete does not work. Yes, I am highlighting the entry with the arrow keys first.
Bug: Download card is shown when Restart to update should be prompted in loss/reaquire of network availability
Status: NEW
Priority: P3
Created: 2020-04-06 14:45:13+00:00
Resolved: 2020-05-12 00:06:36+00:00

###### [Affected versions:]

75.0 	20200403064226 RC2
76.0a1 20200405212522

##### [Affected platforms:]

Windows 10 64bit

Please note that behavior is slightly different on Mac and Ubuntu, additional investigation needs to be done here and probably split into different bugs.

##### [Steps to reproduce:]

In order to easily reproduce this issue you can simulate a poor internet connection by using softwares like NetLimiter.

1. Launch an older version of Firefox (ex. 75 RC2 or few days old Nightly).
2. While the update download is still underway Type “update firefox” inside the Address Bar and cut off internet access before the update is completed.
3. Wait for download to fail.
4. Restore Internet connection.
5. Wait for the update download to be completed.

##### [Expected result:]
The intervention prompts user to Restart to Update, not to Download Firefox.

##### [Actual result:]

At step 2, given the fix in bug 1625241, now the Intervention will properly state Download Firefox.
However, in the case of connection issues, the status will not be translated into Restart to update after the update is downloaded, still prompting the user to download firefox, when the action should be Restart to update.

##### [Note:]
1. Testing on Ubuntu confused me a bit since the tooltip from the hamburger menu is intermittent and I don't know exactly the logic behind it atm.
2. Testing the scenario on esr 68 showed an improvement on the download fail/resume mechanism , esr not being able to tell that the download fails, being stuck at xxx kb until the connection is on again.
3. Depending on where the intervention reads the % completed and the necko status, we might have a different situation on each OS.
4. Setting won't fix for 75 since the STR are a bit edge case and probably too late for 75.