av9ash/GitBugs huggingface dataset:
Bug: Cannot log into ebay after a successful captcha challenge
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-12-21 15:34:46+00:00
Resolved: 2021-01-20 15:14:29+00:00

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

Steps to reproduce:

I attempted to log into my eBay account and was presented with the sliding Captcha challenge.


Actual results:

I successfully completed the Captcha challenge and was presented with the [RESEND][CANCEL] dialogue box. After clicking [RESEND] it normally proceeds to my account dashboard. Now, it just endlessly repeats the Captcha challenge. No matter how many times you successfully complete it and click [RESEND], it will just go back to the Captcha challenge again.

I used eBay just fine last week. I just updated from FF85.0b3 to 85.0b4 today. That's the only change.


Expected results:

After a successful Captcha completion, clicking [RESEND] should proceed to eBay account dashboard.
Bug: Ensure the restoring tab is not reused in addMultipleTabs
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-12-21 16:32:04+00:00
Resolved: 2021-02-23 23:06:51+00:00

See https://bugzilla.mozilla.org/show_bug.cgi?id=1665942#c26.

It's possible that the selected tab is going to be reused but its tab state hasn't been reseted in SessionStore while restoring windows.

The issue was hidden in some cases because the userContextId attribute was undefined which causes bypassing the if-check.
Bug: Pinned Tabs Disappearing When Using Second Window
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-12-21 18:29:21+00:00
Resolved: 2020-12-29 12:14:38+00:00

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

Steps to reproduce:

1. Open FF
2. Pin a couple of tabs
3. Open a second FF window
4. Close the main FF window
5. Close second FF window
6. Open FF again



Actual results:

The pinned tabs are gone


Expected results:

The pinned tabs should be there
Bug: Microsoft Office and other custom protocol handlers requiring user confirmation are broken when used in `window.open("custom:something").close()`
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-12-21 20:52:13+00:00
Resolved: 2021-01-06 12:16:56+00:00

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

Steps to reproduce:

In our product, we support using Microsoft Office custom protocol handlers (the scheme: https://docs.microsoft.com/en-us/office/client-developer/office-uri-schemes) to launch Excel/Word directly from our web app. But for version 84.0, this functionality appears broken. When users are trying to do the same thing, the tab is quickly opened and closed. 

This problem is not present in Chrome or older versions of FireFox. 

Since this is not a ordinary user behavior, I will attach a video for demonstrations. 


Actual results:

Excel/Word cannot be launched


Expected results:

Excel/Word can be launched properly.
Bug: Firefox Accounts- text is missing in the Firefox Accounts setting page
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-12-22 05:52:02+00:00
Resolved: 2020-12-22 17:37:02+00:00

**Build ID :** 20201211215739
**User Agent :** Mozilla/5.0 (Android 10; Mobile; rv:84.0) Gecko/84.0 Firefox/84.0
**OS :** Android 10 Device 

**Steps to Reproduce:**

1/ Login to your Firefox Account
2/ Go to https://accounts.firefox.com/settings
2/ Go to the Settings
3/ Check the top left of the webpage. We see an icon 

**Actual Result:**

'Firefox Accounts' - text is missing beside the icon. 

**Expected Result:**

'Firefox Accounts' - text should be there beside the icon. We we go to the same link(https://accounts.firefox.com/settings) in Desktop with Firefox, we see the text.
Bug: Default search engine telemetry is not updated if the engine is modified
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-12-22 13:00:18+00:00
Resolved: 2023-09-11 11:52:37+00:00

If the details/parameters of the user's default search engine are changed whilst Firefox is running, then the telemetry environment is not updated.

Generally this shouldn't be an issue, however, if we did a live change of parameters on a search url, or if an add-on changed the parameters for a URL that we monitor, then we wouldn't see those reflected in the telemetry environment for that session.

The issue is that we currently only update the data when the environment is initialised, or when the default engine is changed.

https://searchfox.org/mozilla-central/rev/8698fade12984b9a6a43a85a287a5f17e8fd4ddf/toolkit/components/telemetry/app/TelemetryEnvironment.jsm#1376-1382
Bug: Overriding of search engines should be completed before SearchService.init finishes
Status: RESOLVED
Priority: P2
Resolution: WONTFIX
Created: 2020-12-22 14:49:59+00:00
Resolved: 2021-01-21 19:06:06+00:00

From looking at telemetry I noticed a couple of issues with the overriding of search engines:

* The environment telemetry has the wrong submission URL if Firefox has been restarted after installing the add-on.
* If the user uses a `--search` command line option to start Firefox (or I guess calling from an external app), then the search will have the parameters of the normal engine rather than the overridden engines.

The main issue here is that rather than handling the overrides as part of initialisation, we wait until initialisation is complete, and then handle them. As we've waited, there's a short time where other things like the above can get in, and get the wrong parameters/details.

Bug 1683860 would help the telemetry side, although it may cause two environment pings to happen.

I think we should investigate moving the handling of the override to happen at the end of the initialisation sequence, it might be that we need an "init completed enough for add-on manager interactions" state.
Bug: Firefox Sync sends lots of chatter to my system logs every minute
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-12-22 15:29:39+00:00
Resolved: 2022-11-28 02:45:13+00:00

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

Steps to reproduce:

journalctl -f


Actual results:

I see the attached result in my logs, with Firefox generating about 124 lines every minute (somehow categorized under the "gnome-shell" process according to systemd's journalctl, I'm not sure why)


Expected results:

Is it really necessary to send this to the system logs everytime Firefox Sync runs?
Bug: Security Certificate Technical Details Bit Length Incorrect
Status: RESOLVED
Priority: P2
Resolution: INVALID
Created: 2020-12-22 17:22:02+00:00
Resolved: 2021-01-05 21:34:20+00:00

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

Steps to reproduce:

Clicked lock icon in address bar > Connection secure > More Information.


Actual results:

I noticed the Connection Encrypted details in the Technical Details section incorrectly states the website is protected by a 256 bit key.  It is protected by a 256 byte key (2,048 bits).


Expected results:

Clicking View Certificate opens a page with the correct information:

Algorithm = RSA
Key Size = 2048

The Technical Details > Connection Encrypted summary should be corrected to state either a) "256 bytes" or b) "2,048 bits".
Bug: Cross-origin information leakage via redirected PDF requests
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-12-22 18:53:13+00:00
Resolved: 2021-04-05 02:08:33+00:00

I posted a write-up of a vulnerability in the networking code of PDF.js at https://github.com/mozilla/pdf.js/issues/12744
In short, when multiple network requests are sent for parts of the PDF file, responses that belong to a different origin (e.g. due to redirects) should be rejected. This does not happen.

After some code inspection, I found that the vulnerability can currently be exploited under some specific circumstances circumstances. The only requirements for exploitation are:

- Victim website (from where cross-origin data is stolen) responds to Range requests with HTTP 206.
   - note: the fact [that HTTP 206 is required](https://searchfox.org/mozilla-central/rev/5a90b263f71b558fd14bade65b0c4ae5e216e646/toolkit/components/pdfjs/content/PdfJsNetwork.jsm#171-183) slightly lessens the impact, since it means that servers that don't respond to Range requests (I suppose most regular web content would more likely respond with HTTP 200 than 206) aren't affected.
- Limited user interaction: User must click once in an attacker-controlled area (rendered PDF file).

To carry out the attack:

1. Prepare a server that serves the head and tail of a crafted PDF file that triggers the Range request mode of PDF (=loading PDF data in chunks over the network). In between the head and tail, at a well-chosen offset, there are redirects for Range requests to the victim website.
2. To the PDF viewer, the generated PDF file looks like a regular PDF file that contains a link (e.g. the `GoToR` action).
3. By the construction of the PDF at step 1, any click within the PDF file will trigger a navigation to the URL, and the URL will contain the cross-origin data (from the redirection target).
4. To execute the exploit, the user must be tricked into clicking in the PDF.

I haven't attached a PoC because I haven't bothered with constructing a PoC server with a good head/tail + offsets that triggers the vulnerable code path in PDF.js, but I did create such a PoC before in https://crbug.com/653749 (CVE-2016-5206).
Bug: The printing popup opens when opening some pdf files
Status: NEW
Priority: --
Created: 2020-12-22 19:39:27+00:00
Resolved: 2022-02-24 18:06:07+00:00

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

Steps to reproduce:

Open the pdf attached to this bug report.


Actual results:

Immediately on opening, the printing modal opens as well.


Expected results:

The printing modal should not open.
Bug: When downloading .m4a from zoom.us Recordings page, shows as .mp4 on Firefox revision 84.0 -- all previous versions allowed the download of .m4a correctly.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-12-22 19:48:54+00:00
Resolved: 2021-01-21 13:07:14+00:00

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

Steps to reproduce:

Tested on versions 82.0, 83.0 and 84.0
Logged into zoom.us website, went to Recordings page and clicked the download button for Audio Only

82.0 - Comes across as m4a
83.0 - Comes across as m4a
84.0 - Comes across as mp4


Actual results:

84.0 revision shows .mp4 for download when should be m4a.


Expected results:

All revisions should be coming across as m4a, as that is the intended file format.
Bug: Built-in eBay search engine just sends people to ebay.com when there are multiple words in a search query
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-12-23 02:47:45+00:00
Resolved: 2021-02-17 11:42:38+00:00

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

Steps to reproduce:

I used tab-to-search to search eBay, and typed in a multi-word search such as "apple watch."


Actual results:

I got sent to ebay.com.


Expected results:

I should have gotten sent to the search page on eBay for that search query.

Tested on Firefox 84, reproducible on Firefox Nightly 86.
Bug: Offline 84.0.1 download version is 84.0.0
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-12-23 07:15:03+00:00
Resolved: 2021-01-18 17:49:25+00:00

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

Steps to reproduce:

Downloading 84.0.1 Offline .exe


Actual results:

The "Firefox Setup 84.0.1.exe" file includes the 84.0.0 version.


Expected results:

Getting the version which is in the file name.
Bug: Intermittent uriloader/exthandler/tests/mochitest/browser_extension_correction.js | Downloaded file should also match file_as.exe - Got "file_as(1).exe", expected "file_as.exe"
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2020-12-23 07:45:47+00:00
Resolved: 2021-01-19 11:58:35+00:00

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

---
```
task 2020-12-23T06:23:56.103Z] 06:23:56     INFO - TEST-PASS | uriloader/exthandler/tests/mochitest/browser_extension_correction.js | binary/octet-stream should get an extension - 
[task 2020-12-23T06:23:56.103Z] 06:23:56     INFO - Console message: [JavaScript Error: "TypeError: can't access property "postShowCallback", this.dialog is null" {file: "resource://gre/modules/HelperAppDlg.jsm" line: 615}]
[task 2020-12-23T06:23:56.103Z] 06:23:56     INFO - initDialog/<@resource://gre/modules/HelperAppDlg.jsm:615:7
[task 2020-12-23T06:23:56.103Z] 06:23:56     INFO - 
[task 2020-12-23T06:23:56.103Z] 06:23:56     INFO - Download changed!
[task 2020-12-23T06:23:56.103Z] 06:23:56     INFO - Download succeeded or errored
[task 2020-12-23T06:23:56.104Z] 06:23:56     INFO - Buffered messages finished
[task 2020-12-23T06:23:56.104Z] 06:23:56     INFO - TEST-UNEXPECTED-FAIL | uriloader/exthandler/tests/mochitest/browser_extension_correction.js | Downloaded file should also match file_as.exe - Got "file_as(1).exe", expected "file_as.exe"
[task 2020-12-23T06:23:56.104Z] 06:23:56     INFO - Stack trace:
[task 2020-12-23T06:23:56.104Z] 06:23:56     INFO - chrome://mochikit/content/browser-test.js:test_is:1332
[task 2020-12-23T06:23:56.104Z] 06:23:56     INFO - chrome://mochitests/content/browser/uriloader/exthandler/tests/mochitest/browser_extension_correction.js:checkDownloadWithExtensionState:79
[task 2020-12-23T06:23:56.104Z] 06:23:56     INFO - Leaving test bound test_broken_saved_handlerinfo_and_useless_mimetypes
[task 2020-12-23T06:23:56.105Z] 06:23:56     INFO - Console message: [JavaScript Error: "Unix error 2 during operation setPermissions on file /Users/cltbld/Downloads/file_as(1).exe (No such file or directory)" {file: "resource://gre/modules/DownloadIntegration.jsm" line: 683}]
[task 2020-12-23T06:23:56.105Z] 06:23:56     INFO - downloadDone@resource://gre/modules/DownloadIntegration.jsm:683:12
[task 2020-12-23T06:23:56.105Z] 06:23:56     INFO - 
[task 2020-12-23T06:23:56.105Z] 06:23:56     INFO - GECKO(2428) | MEMORY STAT | vsize 7891MB | residentFast 443MB | heapAllocated 177MB```
Bug: Port 554 Blocked after Update 84.0 (Linux)
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-12-23 07:50:52+00:00
Resolved: 2021-06-11 11:12:17+00:00

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

Steps to reproduce:

After Update to FF  84.0 (Linux) the Port Port 554 is Blocked.

Message: 
Fehler: Port aus Sicherheitsgründen blockiert
Die aufgerufene Adresse fordert einen Port, der normalerweise nicht zum Browsen im Web verwendet wird. Die Anfrage wurde zu Ihrem Schutz abgebrochen.

Error: Port blocked for security reasons

The address called requests a port that is not normally used for web browsing. The request was canceled for your protection.
Bug: Bookmarked separators cause Bookmark menus to show partial blank dropdowns
Status: NEW
Priority: P3
Created: 2020-12-23 09:20:29+00:00
Resolved: 2021-01-19 14:25:54+00:00

**Affected versions**
* 85.0b4, 86.0a1

**Affected platforms**
* macOS 10.15, Win10, Ubuntu18;

**Steps to reproduce**
browser.toolbars.bookmarks.2h2020 set to true
1. Launch Firefox, enable the bookmarks toolbar, remove all bookmarks from it;
2. Click to open the Firefox menu;
3.  Hover on the Bookmarks section;
4. In the bookmarks toolbar, add a separator;
5. Click to open the Firefox menu;
6.  Hover on the Bookmarks section;

**Expected result**
a. menu shows the [Empty] dropdown;
b. menu option does not have the expand triangle;

**Actual result**
* on macOS the menu is not opened;
* on Win10 a small menu is open, partial width of expected length;

**Regression range**
* not a regresssion;

**Additional notes**
* attached screenshot with the issue;
* set S4 due to the unlikely-ness of ending up in this scenario.
Bug: switch to tab kills the current window
Status: RESOLVED
Priority: P5
Resolution: WONTFIX
Created: 2020-12-23 10:39:53+00:00
Resolved: 2023-05-01 20:51:57+00:00

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

Steps to reproduce:

I have 2 firefox windows open. one with a facebook tab open. the other window has no tabs. I type facebook and it gives me the option to switch to the tab. I click the option.


Actual results:

My current window with no tabs closes.


Expected results:

Control passes to the window with the facebook tab and the existing window is unaffected.
Bug: FF 84.0 causing QTS to immediately logout upon sign-in
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-12-23 12:47:17+00:00
Resolved: 2021-01-14 08:04:47+00:00

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

Steps to reproduce:

auto update to v84.0 and subsequently to v84.1


Actual results:

QNAP's QTS 4.5.1 browser/web interface will not accept any log-in; instead logs off immediately; 


Expected results:

sign-in to QTS as in versions prior to v84.0
Bug: Firefox crashes when downloading multiple big files at the time
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-12-23 15:19:33+00:00
Resolved: 2021-01-14 08:05:35+00:00

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

Steps to reproduce:

On Mac OS X, queue for download multiple (10) big files (2GB)


Actual results:

Firefox crashes


Expected results:

Complete the downloads successfully.
Bug: reconnect to firefox account
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-12-23 17:29:49+00:00
Resolved: 2022-10-10 16:25:00+00:00

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

Steps to reproduce:

Power up computer next day. Computer - Windows 10 Pro all updates current. Malwarebytes installed all updates current.


Actual results:

About a month ago (sorry can't be more specific) after a Firefox update, I noticed that after booting up my computer, Firefox wanted me to 'reconnect' to my account. Thinking that maybe this was an enhanced security service (must login every so often) I did not think much of it. Then I noticed that I was getting the "Reconnect to Firefox Account" everyday. 

If I logged in to my account I stayed logged in for the rest of that day, no matter how many times I closed Firefox and opened Firefox or re-started my computer. Usually I startup my system in the morning and when I am finished I 'shut down'. 

Power up the next day (literally the next day - new date mm/dd/yy), start Firefox, see my image, think all is cool, then in about 10 seconds, my image disappears and I get the "reconnect to firefox account". 

I have no synced devices (or Firefox running on another device currently). Previously, I had Firefox on my Android Galaxy phone and on my iPad. But I deleted those instances after Firefox performed and update that changed the way Favorites were presented on the phone, and limitations imposed by Apple/Safari that crippled Firefox behavior on the iPad).

Checking my Firefox account 'Sync' on Windows/Firefox, there are no devices listed except my desktop.

Based on other reports concerning  "reconnect to firefox account" I tried logging out of my account, logging in my account only - no -sync. I've exported my bookmarks, deleted Firefox off of my Windows computer, downloaded and reinstalled Firefox, all to no avail.

The next day, date change, I am always presented with the "reconnect to firefox account".

Don't know why or don't understand what a day/date change has to do with this, but it is always the next day when "reconnect to firefox account" shows up again.


Expected results:

The way Firefox behaved before is what should have happened. You should stay logged into your account no matter how many times you restart your computer or how many days pass before your power your system back up. 

You should stay logged in  - until you either: log off, delete re-install Firefox.
Bug: Microphone list is wrong when shown from the Skype add-on
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-12-23 23:02:37+00:00
Resolved: 2020-12-24 19:27:19+00:00

User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

In Firefox 84.0 on FreeBSD 12:
1. Installed skype-for-web add-on.
2. Logged into the skype account
3. Went to "Calls" -> "Skype Test Call"



Actual results:

Firefox offered to use only one microphone, while many microphones are available.

When regular websites, like https://www.onlinemictest.com/ , offer to enable microphone - all microphones appear in the list.



Expected results:

All microphones should be offered in a prompt activated by the Skype add-on, like they are shown for regular websites.
Bug: ESNI won't work on Firefox 85 beta
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-12-24 00:15:45+00:00
Resolved: 2020-12-24 09:53:50+00:00

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

Steps to reproduce:

Visit the ESNI checker page https://www.cloudflare.com/ssl/encrypted-sni/ and start the test. Tested on Windows and on Android.


Actual results:

ESNI won't work but FF 84 does


Expected results:

The ESNI test should be passed.
Bug: In 84.0.1 Bookmark toolbar vanished - CMD-B shows the books marks are still there
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-12-24 00:58:25+00:00
Resolved: 2020-12-24 09:05:54+00:00

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

Steps to reproduce:

Run Firefox 84.0.1


Actual results:

No bookmarks toolbar below the search, home, add=ons, etc.


Expected results:

As in all previous versions the bookmark toolbar appeard
Bug: "Open applications" permission isn't in either of the permission lists
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-12-24 02:05:26+00:00
Resolved: 2020-12-24 13:37:52+00:00

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

Steps to reproduce:

1. Go to https://t.me/themes
2. After the site loads, Firefox opens a dialogue titled "Allow this site to open the tg link?"
3. Click on the "Always allow https://t.me to open tg  links" checkbox, then on "Choose Application". 
4. Firefox opens another dialogue, titled "Choose an application to open the tg link.". Click on "Cancel".
5. After step 3 a permissions icon right to the padlock icon and left the site address appears. Clicking on it shows that https://t.me is now allowed to Open applications, specifically, tg:// links.

Not quite sure whether it's a bug, but that type of permission ("Open applications") is absent both from the "Page Info (Ctrl+I) -> Permissions" and "about:preferences#privacy -> Permissions" lists.