av9ash/GitBugs huggingface dataset:
Bug: The "Archive in Pocket" and the "Delete from Pocket" options are still displayed in the "Recommended by Pocket" card's menu even if you are no longer logged in to Pocket
Status: NEW
Priority: P2
Created: 2022-03-08 13:46:13+00:00
Resolved: 2023-06-12 15:17:38+00:00

**[Affected versions]:**
- Firefox Release 98.0 - Build ID: 20220304153049
- Firefox Beta 99.0b1 - Build ID: 20220308094525
- Firefox Nightly 99.0a1 - Build ID: 20220308092232

**[Affected Platforms]:**
- Windows 10 x64
- macOS 11.6.2
- Linux Mint 20.2 x64

**[Prerequisites]:**
- Have a Firefox profile with the "browser.search.region" pref set to "US" in the "about:config" page.
- You are logged in to Pocket.

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Open a new tab and hover any "Recommended by Pocket" card.
3. Click the menu button from the top-right part of the card.
4. Select the "Save to Pocket" option.
5. Navigate to "https://getpocket.com/my-list" and click the "Account" button from the top-right part of the page.
6. Select the "Log Out" option and open a new tab.
7. Observe the context menu of the previously saved to "Pocket" card.

**[Expected result]:**
- The following options are displayed:
 - "Bookmark; 
 - "Save to Pocket;
 - "Open in a New Window";
 - "Open in a New Private Window";
 - "Dismiss".
    
**[Actual result]:**
- The "Archive in Pocket" and the "Delete from Pocket" options are still displayed.

**[Notes]:**
- This issue is still reproducible if another card is dismissed, the page is refreshed or a new tab is opened.
- This issue is no longer reproducible after a browser restart.
- Attached a screen recording of the issue:
Bug: Can't determine the download source for in-progress downloads
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-03-08 20:53:56+00:00
Resolved: 2022-03-21 10:12:27+00:00

Steps to reproduce:

1. Set browser.download.improvements_to_download_panel to true (should be the default on Firefox 98).
2. Configure Firefox to always ask where downloads are to be saved in about:preferences#general .
3. Download something, e.g. https://de.download.nvidia.com/Windows/497.09/497.09-desktop-win10-win11-64bit-international-dch-whql.exe .


Actual results:

A window pops up that allows you to navigate to a location and save the file without a way for the user to tell from which source the file is from before downloading it.


Expected results:

See below.


Additional details:

With the old download panel ( browser.download.improvements_to_download_panel=false ) Firefox did show the protocol[1] and source of the download so the user could check if the download is from an encrypted connection and the source is trustworthy - as the information from which website the download was triggered alone is not always sufficient - e.g. if I download now a driver from the NVIDIA homepage all is fine even if I can't see the actual source of the download since I would trust https://www.nvidia.com that triggers the download here but if another unknown host links to the same file there would be no trust anymore with the new download panel improvements but with browser.download.improvements_to_download_panel=false I could still see that the source file points to nvidia.com and thus can be trusted.

I fear the best solution would be to still somehow show the source of the download before/when the user decides where to save the file to, but this is probably now undesired and hard to fix I assume. If that is true an alternative might be to show the download source for each download in the download panel's doorhanger/site -  eventually only in the tooltip when the user hovers over the related download.

The best (and pretty tedious) workaround for this issue is currently if the user saves the file to a location (and thus downloads it without guaranteed .part protection) first, switches then to the download panel, makes a right click to the related entry, copies the download link and then opens/pastes the link into an editor to check it.


[1]At least for the http(s) part the new download panel improvements warn the user whenever a download is from an insecure connection (independent of the setting to ask where a file should be downloaded) and only creates a 0 byte file or a non-zero-byte file with a .part filename ending.
Bug: New Version of Firefox.  Cannot specify an application to start  for file type .qfx
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-03-08 23:22:26+00:00
Resolved: 2022-04-28 15:47:04+00:00

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

Steps to reproduce:

I am using windows 7
Installed V98
Signed on to my normal website.
requested to download a file
This worked an hour ago.


Actual results:

Firefox did not provide a default application to start for this file type.
The only choice was save the file.
I cannot find the correct keystrokes to force firefox to open quicken for this file type.



Expected results:

If the file type is unknown to firefox. it should ask for a default application to use now and in the future.
Bug: Firefox 98 no longer allows me to choose download filename
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-03-09 03:27:53+00:00
Resolved: 2022-04-04 15:38:33+00:00

Steps to reproduce:

Firefox 98 on Windows 10 suddenly forces files to be downloaded immediately in the Download filter using some default filename. The release notes say "Instead of prompting every time, files will download automatically." This bad. This is wrong. This is contrary to my explicit settings.

This is a big problem. If Firefox persists in _not_ following my configuration and forcing me to automatically download files without changing their filename, this will be what sends me (an adamant Firefox user) to Chrome.

I explicitly have my Firefox setting under "Downloads" set to "Always ask you where to save files".


Actual results:

With Firefox 98, Firefox does not honor "Always ask you where to save files". It does not ask me where to save file. It just saves the file in "Downloads".


Expected results:

In previous versions of Firefox, with "Always ask you where to save files" selected I would not only be able to select the download folder, but I would also be able to choose a filename.

Imagine you download a bank statement in PDF format every month. Imagine it is named something like `STATEMENT0322.PDF`. In previous versions of Firefox, I could select the "My Bank" folder and rename the file to `bank-statement-2022-03.pdf`. Now Firefox immediately dumps the file into Downloads (I don't want it there) and names it `STATEMENT0322.PDF`.

This is a huge problem. It is a blocker. And beyond this it is not even honoring my explicit settings that say, "Always ask you where to save files". It boggles my mind this reached users; it seems like the sort of inane screwup that Microsoft would do.

Please reverse this immediately. You will be driving even Firefox fans to Chrome.
Bug: Screen reader reads highlighted text separately
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2022-03-09 05:13:17+00:00
Resolved: 2023-06-02 15:22:57+00:00

STR:
1. Enable VoiceOver
2. Type any char in URL bar.
3. Select roww by keydown.

Actual:
  VoiceOver reads highlighted text separately.
Expect:
  It should be read with the correct delimitation.

I attach a video. In this example, I input “exa” in URL bar. Then, select the results by order. As we can see the text of VoiceOver, “example” separates to “exa” and “mple” (we can see  white space between “exa” and “mple”), then it will be read out separately. Screen reader should read out “example”, I think.

It seems that this issue happens on not only OSX but Windows with NVDA as well.
Bug: Largeish downloads to a Windows file share do not complete
Status: RESOLVED
Priority: P1
Resolution: INCOMPLETE
Created: 2022-03-09 08:46:59+00:00
Resolved: 2022-08-09 21:02:26+00:00

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

Steps to reproduce:

Downloaded a large 547 MB file to a remote folder shared via SMB/CIFS


Actual results:

After the download (almost) completes, it takes many minutes for the download to process. The Firefox Downloads dialog says:

"A few seconds left — 547 of 547 MB (686 KB/sec)"

Windows File Explorer shows a 0 KB download file with name matching the download, and a .PART file of the expected size of the download which takes many minutes to disappear, after which the downloaded file is then the expected size.

I've been able to replicate this twice now, with different files from different sites. This is on a LAN with gigabit links and no other connectivity issues.


Expected results:

If I download the file to my local drive, the download completes without issue.
Bug: "Go To Download Page" leading to wrong page
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-03-09 09:55:35+00:00
Resolved: 2022-04-26 17:51:45+00:00

This probably depends on the details on how the site initializes the downloads, but I don't have a public repro case.

STR:
1) Initiate a bunch of downloads.
2) Download picture from photos.google.com.
3) Right click a previous download, "Go To Download Page".
4) Arrive at the photos.google.com (site corresponding to first download), not the site for the actual download.

In the screenshot, I would right-click the anode.com link, but end up on photos.google.com.
Bug: The environment cannot be switched anymore between "Prod" and "Stage" using the "XPCSHELL_TEST_PROFILE_DIR=foo" variable
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-03-09 09:57:07+00:00
Resolved: 2022-12-13 00:04:15+00:00

**[Notes]:**
- We received a workaround for this issue, more exactly we need to enter the `XPCOMUtils.defineLazyPreferenceGetter(ChromeUtils.import("resource://services-settings/Utils.jsm").Utils, "SERVER_URL", "services.settings.server")` code in the "Browser Console" before changing the environment. However, this workaround does not help us in the case of first-run experiments where we need to change the environment before opening the browser.

**[Affected versions]:**
- Firefox Beta 99.0b1 - Build ID: 20220308094525

**[Affected Platforms]:**
- Windows 10 x64
- macOS 11.6.2
- Linux Mint 20.2 x64

**[Steps to reproduce]:**
1. Open a "Command Prompt" window ("Terminal" on macOS and Linux).
2. Enter the `set XPCSHELL_TEST_PROFILE_DIR=foo" variable ("export XPCSHELL_TEST_PROFILE_DIR=foo" on macOS and Linux) and press the "Enter" key.
3. Open the browser from the above "Command Prompt/Terminal".
4. Install the "[Remote Settings Devtools](https://github.com/mozilla-extensions/remote-settings-devtools/releases)" addon.
5. Click the "Remote Settings Devtools" toolbar button.
6. Select the "Stage" option from the "Environment" dropdown placed in the top-right part of the page.
7. Observe the behavior.

**[Expected result]:**
- The "Stage" environment is successfully selected.

**[Actual result]:**
- The "Prod" environment is still selected.

**[Regression Window]:**
- According to Ed Lee it seems that bug 1272255 has caused this behavior.

**[Additional Notes]:**
- Attached a screen recording of the issue:
Bug: [Mac] Text is not visible at hover on about:config page on high contrast settings.
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-03-09 14:49:29+00:00
Resolved: 2022-04-11 07:04:56+00:00

**Affected versions**
* Beta 99.0b1 (64-bit)

**Affected platforms**
* macOS 10.13

**Steps to reproduce**
1. Set High contrast on Mac 10.13 (System preferences->Accessibility->Display->check Increase contrast).
2. Open Firefox and go to "about:config" page.
3. Set browser.search.region to "US".
4. Hover the "US" string.

*Actual results:*
At hover text is not visible (see screenshot attached).

*Expected results:*
Text should be visible.

**Suggested Severity**
* S4, since it is a display issue.
* Issue is reproducing only on Mac Os.

**Regression range**
* I've reached the following regression range:
Last good 2021-02-12
First bad: 2022-03-09
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5ea572e916522c6a1a96daef9f37427ab245ed57&tochange=2e8c89be4b84caa728fdc36225127efd539dc63c
Bug: Bolded line is displayed inside context menus when using High contrast white
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-03-09 15:05:17+00:00
Resolved: 2023-01-05 14:01:48+00:00

*Affected versions*
* 100.0a1 (2020-02-25)
* 99.0b1
* 98.0




*Affected platforms*

* Windows 10x64

*Preconditions*
* High contrast White enabled

*Steps to reproduce*
1. Open Firefox and a random context menu.





*Expected result*
* The separating line looks the same.

*Actual result*
* Small bolded line displayed on the left side.

*Regression range*
* I will search for one ASAP.



*Notes*
* Screenshot attached.
Bug: 4.16 - 3.14% buzzfeed ContentfulSpeedIndex / buzzfeed SpeedIndex + 1 more (Windows) regression on Thu March 3 2022
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-03-09 15:56:44+00:00
Resolved: 2022-04-26 17:54:14+00:00

Perfherder has detected a browsertime performance regression from push [b3b8027d490283106126f7b8d30b966e18c14828](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=b3b8027d490283106126f7b8d30b966e18c14828). As author of one of the patches included in that push, we need your help to address this regression.

### Improvements:

| **Ratio** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--| 
| 4% | [buzzfeed](https://firefox-source-docs.mozilla.org/testing/perfdocs/raptor.html#buzzfeed-d) ContentfulSpeedIndex | windows10-64-shippable-qr | cold fission webrender | 871.67 -> 835.42 |
| 4% | [buzzfeed](https://firefox-source-docs.mozilla.org/testing/perfdocs/raptor.html#buzzfeed-d) SpeedIndex | windows10-64-shippable-qr | cold fission webrender | 771.25 -> 740.42 |
| 3% | [buzzfeed](https://firefox-source-docs.mozilla.org/testing/perfdocs/raptor.html#buzzfeed-d) SpeedIndex | windows10-64-shippable-qr | cold fission webrender | 757.54 -> 733.75 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=33493), including links to graphs and comparisons for each of the affected tests. Please follow our [guide to handling regression bugs](https://wiki.mozilla.org/TestEngineering/Performance/Handling_regression_bugs) and **let us know your plans within 3 business days, or the offending patch(es) will be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).
Bug: Live language Search switch Wikipedia localized engine is not switched
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-03-09 17:25:48+00:00
Resolved: 2022-04-05 12:57:40+00:00

##### [Description:]
Wikipedia has most engines localized, live switching requires the localized wikipedia engines to be changed.

##### [Environment:]
99.0b1 (2022-03-09)
100.0a1 (2022-03-09)

Mac 11
Windows 10

##### [Preconditions:]
user_pref("intl.multilingual.downloadEnabled", true);
user_pref("intl.multilingual.enabled", true);
user_pref("intl.multilingual.liveReload", true);
Install:
[language-pack zh-cn](http://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/linux-x86_64/xpi/firefox-100.0a1.zh-CN.langpack.xpi)
[language-pack ca](http://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/linux-x86_64/xpi/firefox-100.0a1.ca.langpack.xpi)

##### [Steps:]
1. Install a firefox Firefox locale, en-us for example (autoset region not that relevant).
2. Install language packs from the preconditions.
3. Open about:preferences / Language.
4. Switch the language to zh-cn.
5. Open a new tab with about:preferences / search and check engines
6. Open new tab and try to search using the wikipedia engine.

##### [Actual Result:]
5. Engines are shown correctly with zh-cn localization applied
6. The search cannot be completed, en.wikipedia is removed but not replaced with cn.wikipedia (TypeError: can't access property "getSubmission", engine is null)

##### [Expected Result:]
5. Engines are shown correctly with zh-cn localization applied
6. before_language _switch_wikipedia is swapped with the after_language_switch_wikipedia.

##### [Regression Range:]
Not a regression.
Bug: Live language Search search preferences are not refreshed.
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-03-09 17:30:46+00:00
Resolved: 2022-04-12 15:20:57+00:00

##### [Description:]
When live switching engines, the about:preferences#search engine list is not refreshed.

##### [Environment:]
99.0b1 (2022-03-09)
100.0a1 (2022-03-09)


Mac 11
Windows 10
Ubuntu 20

##### [Preconditions:]
user_pref("intl.multilingual.downloadEnabled", true);
user_pref("intl.multilingual.enabled", true);
user_pref("intl.multilingual.liveReload", true);
Install:
[language-pack zh-cn](http://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/linux-x86_64/xpi/firefox-100.0a1.zh-CN.langpack.xpi)
[language-pack ca](http://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/linux-x86_64/xpi/firefox-100.0a1.ca.langpack.xpi)

##### [Steps:]
1. Install a firefox Firefox locale, en-us for example (autoset region not that relevant).
2. Install language packs from the preconditions.
3. Open about:preferences / Language.
4. Switch the language to zh-cn.
5. Click on Search section from about:preferences and check engines


##### [Actual Result:]
Switched engines are not shown to their cn version (easily spotted with switch from en-us to zh-cn) unless about:preferences is refreshed.

##### [Expected Result:]
Switched engines are shown their switched to their cn version as soon as switched.

##### [Note:]
Setting S4 severity since this is a pretty old known issue for the about:preferences refresh.
Bug: The Temp Folder has become the Download Folder
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-03-09 19:25:46+00:00
Resolved: 2022-03-10 14:50:22+00:00

Steps to reproduce:

I opened a file, like usually (a PDF, for example)


Actual results:

It has automatically downloaded into my Download Folder, although I just wanted to open it.


Expected results:

It should have only been downloaded into the Temp folder, and not the Download Folder, because I didn't request its download, I just needed to open it. The problem is now that every opened file pile up into the Download Folder and all this has to be manually deleted afterwards. This behavior was not present prior to Firefox 98. The Temp Folder and the Download Folder used to be separate and this feature was unique to Firefox. Please make it back the way it was before because it's hard now to get rid of the files that you just want to open, and not to download.
Bug: Files & Applications > Always ask option is not working after new update
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-03-09 20:51:23+00:00
Resolved: 2022-04-29 13:26:02+00:00

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

Steps to reproduce:

In settings > Files & Applications > Downloads I have Firefox setup to "Always ask where to save files", after the new update to Firefox this morning it appears that is not working.  Files are downloading immediately upon clicking on them.  It appears it is looking at the specific choices for the Applications instead.


Actual results:

Clicked on a file, it immediately downloaded without asking.


Expected results:

It should have asked where to save the file.
Bug: Clear a single item from the address bar history does not work
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-03-09 21:33:49+00:00
Resolved: 2022-03-29 16:22:00+00:00

Steps to reproduce:

Clear a single item from the address bar history:
1.   Type or paste enough text for Firefox to show the item in the drop-down.
2.   Press the ↓ down arrow key or move the mouse, to highlight the item.
3.    Hold down the Shift key and press Delete on your keyboard. 

(you may refer to https://support.mozilla.org/en-US/kb/remove-websites-address-bar-suggestions )


Actual results:

The single item is not cancelled


Expected results:

The single item must be cancelled
Bug: browser.download.panel.shown gets re-enabled on every download
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-03-09 21:47:59+00:00
Resolved: 2022-03-10 15:16:46+00:00

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

Steps to reproduce:

Right-click an image, select "save image as". The download panel opens (this is undesired; I'll open it if I need it, I don't need it jumping in my face every single time). 
To combat the problem, I set browser.download.panel.shown to false.
Right-click an image, select "save image as". The setting for browser.download.panel.shown gets automatically re-enabled, and the download panel opens again. Why even bother having a setting if you are just going to overwrite it every time?


Actual results:

The download panel keeps popping up when it is not needed. 


Expected results:

It should respect my setting for browser.download.panel.shown when I set it to false.
Bug: v98 Downloads panel pops up incorrectly when opening files as pages in Firefox
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-03-09 22:52:53+00:00
Resolved: 2022-09-02 19:11:28+00:00

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

Steps to reproduce:

The new and improved Downloads panel in v98 is advertised as:
*This means you’ll experience minimal interruptions and easily find your downloaded files.*

The current implementation must be erroneous as it results in the exact opposite: the panel shows up when it should not, in an extremely disruptive fashion, and the system Downloads folder is polluted with files that should not be there.


Actual results:

Under "Files and Application Settings", I have selected "Always ask you where to save files", and for the vast majority of the individual files associations, I have "Always ask" as the action on download.

Vast majority of "downloads" that I do are the PDF files I work with daily.
When clicking on a link that serves a PDF, I am always presented with a dialog - open in Firefox, save to disk, open in Adobe. That part is correct. I do need the dialog, as half of the time I want to "Open in Firefox" and another half - "Save to disk".

Starting with v98, after I select "Open in Firefox", the PDF opens as a page in Firefox, and then two things erroneously happen:
- The Downloads panel pops up and shows the file name being downloaded
- The PDF file that I now have opened as a page saves into my system Downloads folder, effectively turning it into the Temp folder. (As I have noted above, I do *not* have the Downloads folder set as my default destination, I have "Always ask where to save files", so putting any file at all automatically into the system "Downloads" folder is erroneous behaviour.)

So each and every time, after opening a PDF in Firefox, I have to 1) Close the useless Downloads popup, and 2) Locate the unwanted file in the Downloads folder and delete it (which may be really tricky given the nonsensical names, often GUIDs).

I literally spent half of today fighting the Downloads panel that kept appearing on each PDF view. I can testify that it is a major annoyance and goes very much against the entire experience of "open in Firefox", where the file opens as if it was but another web page.


Expected results:

When the downloaded file is "Opened in Firefox" (e.g. a PDF):
- The Downloads panel should not show up
- The file should not be automatically saved into the system Downloads folder

When the downloaded file is "Saved to disk" into a user-provided folder:
- The Downloads panel should not show up (it's simply pointless - I have just manually selected a folder to save the file, I don't need to be immediately told what folder I just selected)