av9ash/GitBugs huggingface dataset:
Bug: Dragging any files from download list on toolbar results in first file being moved
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-04-11 14:35:07+00:00
Resolved: 2022-04-12 23:24:52+00:00

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

Steps to reproduce:

If I click on the download list on the toolbar, it shows the 5 most recent downloads.
By dragging any file on the list onto a folder or upload area on the browser, it should move the file that is being dragged on the list.

However, when dragging the files on the list other than the first one, the most recent downloaded file on the download list on the toolbar will be moved instead of the dragged file. This does not happen in the download list in the Library opened by clicking on "Show All Downloads", as it copies the file being dragged correctly.


Actual results:

The most recent file on the download list in the toolbar is chosen instead of the one being dragged. This results in the wrong file being moved or uploaded.


Expected results:

By dragging the chosen file that is not the most recent on the download list in the toolbar, the one that is being dragged should be moved, instead of the most recent one.
Bug: [Windows 10 x64] The “Thank you” spotlight modal is not correctly displayed when Narrator screen reader is used
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2022-04-11 14:53:20+00:00
Resolved: 2022-04-12 07:22:45+00:00

**[Affected versions]:**
- Firefox Beta 100.0b4 - Build ID: 20220410195727
- Firefox Nightly 101.0a1 - Build ID: 20220411094830

**[Affected Platforms]:**
- Windows 10 x64, version 21H1, OS build 19043.1586
- Windows 10 x64, version 21H2, OS build 19044.1586

**[Prerequisites]:**
- Have a Firefox Beta 99 installed.
- Have a new Firefox profile.
- Have the “Narrator” screen reader installed and opened.

**[Steps to reproduce]:**
1. Open the browser from prerequisites.
2. Update the browser to the latest version.
3. Observe the “Thank You” spotlight.

**[Expected result]:**
- The “Thank you” spotlight is correctly displayed and all the elements can be successfully accessed through the screen reader.

**[Actual result]:**
-  The “Thank you” spotlight is being cut off on the left-hand side when the “Narrator” screen reader is active.

**[Notes]:**
- This issue is also reproducible after the Narrator screen reader is turned off.
- This issue is not reproducible using the NVDA screen reader.
- This issue is not reproducible on Windows versions <1903.
- Attached is a screen recording of the issue:
Bug: All tabs crashing after update to 100.b4, nsAppShell::Init()
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-04-11 16:28:19+00:00
Resolved: 2022-09-23 18:59:27+00:00

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

Steps to reproduce:

Updated to 100.b4.


Actual results:

After update, all tabs were crashing.


Expected results:

No issues.

Link to Crashes: https://crash-stats.mozilla.org/signature/?product=Firefox&signature=nsAppShell%3A%3AInit&date=%3E%3D2022-04-04T16%3A20%3A00.000Z&date=%3C2022-04-11T16%3A20%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports

Specific Crash: https://crash-stats.mozilla.org/report/index/ee45a697-c7e9-46e0-ab8e-b977c0220411

I bisected my configuration and narrowed it down to the following preference being the cause:

user_pref("dom.ipc.useNativeEventProcessing.content", true);

Removing that from prefs.js fixed everything up.
Bug: Horizontal scrollwheel goes back after hitting the edges of the horizontal scroll bar
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-04-11 18:21:04+00:00
Resolved: 2022-04-11 18:36:40+00:00

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

Steps to reproduce:

1 (optional). Find a horizontal scroll bar
2. Scroll the horizontal scroll wheel on your mouse in either direction until you hit the 'edge' and can't scroll any further
3. Try to scroll a bit further
4. See that your browser either goes back or forward

Extra info:
Step 1 is optional because if there is NO horziontal scroll bar, the horizontal scroll wheel just goes backward/forward by default.

This seems to be a problem in Firefox Developer Edition, at least version 100.0b3 on MacOS. I am using the MX Master 3 mouse. Firefox (regular) version 99 doesn't seem to have this problem. Google Chrome works fine too.

I checked my about:config for options related to the mouse scrolling, and nothing worked. See https://support.mozilla.org/nl/questions/1373803?utm_campaign=questions-reply&utm_source=notification&utm_medium=email#answer-1496590


Actual results:

My browser went back or forward


Expected results:

Nothing should happen.
Bug: Occasionally, the focus event fails to fire when focusing a textarea in a cross-origin iframe
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-04-11 18:23:44+00:00
Resolved: 2022-04-11 19:00:30+00:00

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

Steps to reproduce:

1) Create a docker container that serves an HTML file containing an input (container A)
2) Create a second docker container that:
  a) Creates a second HTTP server which serves an HTML file containing an iframe pointing to the file served in contained A.
  b) Runs repeated tests using selenium to check that a click on the iframe input causes the input to focus.

The tests above set up two listeners, one on 'click' events and the second one on 'focusin' events, which both save flags to the document's `window` variable. The flags are then checked to be true. If the focus flag was not set to true, the process is retried up to 5 times, each time checking that the click and focus events occurred. There is a one second wait between attempts.

I have set up a repository with the code needed to reproduce the issue:
https://github.com/rafaelhrtd/firefox_focus_check
To run the tests, execute `batch_test.sh`.


Actual results:

The tests occasionally (read rarely, ~1 / 2000 runs on my computer) fail due to the focus flag being set to `false` after five attempts. I have not observed the click flag having a negative value at the moment of failure, so it appears that the click event is handled correctly, but somehow the focus event is prevented.

The problem does not seem to be caused by selenium. I came across this problem while working on end-to-end tests, and was able to examine Firefox after one of this failures. Attempting to click the input manually did not do anything, and the input would not focus until after I switched to a different Firefox window and then switched back. An example that allows for manual inspection is much harder to set up, however, which is why the linked repository only does it through selenium.


Expected results:

The input should always be focused when it is clicked.
Bug: Save To Pocket popup UI is too bright with dark browser-themes
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-04-11 21:33:35+00:00
Resolved: 2022-04-12 18:33:13+00:00

STR:
1. Activate a dark theme (by e.g. visiting `about:addons`, clicking "Themes", and then clicking the "Enable" Button for Dark)
2. Click the Save-to-Pocket button on the Firefox toolbar.

ACTUAL RESULTS:
Bright white popup.

EXPECTED RESULTS:
Popup with dark background, like e.g. the background that we use for other toolbar panels popups (like the hamburger menu, the page-info button, the bookmarks/history & downloads toolbar-buttons).

It looks like this got a bit more noticeable last week as part of the "Save to pocket refresh" (bug 1746013).  Before the refresh's new UI was activated, the popup was still "light-themed" but it wasn't quite as bright-white as it is now.
Bug: tabs auto reloading
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-04-12 05:30:34+00:00
Resolved: 2022-04-26 20:05:32+00:00

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

Steps to reproduce:

open firefox 98.0 running Fedora 5.16.18-100.fc34.x86_64
open a number of tabs in firefox (rareshare2.me, tvchaosuk.com, discord.com, bom.gov.au)
leave the computer for 1 hour


Actual results:

tabs reload when you click on them


Expected results:

tabs should not reloas
Bug: pdf opens without request
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-04-12 08:02:10+00:00
Resolved: 2022-05-05 15:52:47+00:00

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

Steps to reproduce:

try download mail attachment (pdf-file) from webmailer


Actual results:

Firefox OPENS that pdf file in a new tab. Without any question or warning.


Expected results:

download the pdf-file as requested with the usual dialog
Bug: When opening files, Firefox downloads them to last selected directory instead of %temp% directory
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-04-12 09:41:44+00:00
Resolved: 2022-04-12 23:27:48+00:00

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

Steps to reproduce:

1. In Settings, I have selected "Always ask you where to save files"
2. In Settings, for zip files I have selected "Always ask"
3. Last location that I downloaded a file to was Desktop directory
4. I open a zip file from a web page
5. Select to open it with 7-zip File Manager
6. The file gets opened in 7-zip File Manager, but is also downloaded to my Desktop folder!


Actual results:

The file gets opened in 7-zip File Manager, but is also downloaded to my Desktop folder!


Expected results:

The file should have been downloaded to my %temp% directory, because I chose to open it and not download it. 
This happens with all kinds of files I choose to open from Firefox.
My Desktop is now cluttered with hundreds of zip, torrent, txt, etc. files, which normally reside in the %temp% directory!
Bug: [Win 11] Firefox duplicates in Default Apps in system after an update, which breaks the "Make Firefox Default" automated file type detection and selection
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-04-12 09:50:53+00:00
Resolved: 2022-04-20 06:36:10+00:00

**Affected versions**
- Firefox 100.0b4
- Firefox 101.0a1

**Affected platforms**
- Windows 11

**Steps to reproduce**
1. Install an older Firefox version (ex. 99.0b4)
2. Update the browser to the latest version
3. Access about:preferences and set Firefox as default and have opened the Default apps in Windows 11

**Expected result**
- Firefox is made as default automatically to the supported file types without any other user interaction other than selecting "Make Firefox Default" in about:preferences.

**Actual result**
- After an update to the latest version, Firefox will duplicate in Default Apps in system and this will force the user to manually select the file types when selecting "Make Firefox Default" in about:preferences.

**Regression range**
- Can't search for a regression as Firefox will be updating to the latest version.

**Additional notes**
- The issue can be seen in the following [attachment](https://drive.google.com/file/d/1Lh8D7edH6cK3jVWbZTdU5kMHqR6atGw6/view?usp=sharing). First the browser is made automatically default without problems if it was cleanly installed, but after updating it, it will simply duplicate and break the default functionality.
- This is affecting Windows 11. Windows 10 and below doesn't behave as Windows 11's default app selections.
- By following the steps, Firefox will not be recognized as an option to select for example PDF handle in Default App in Win 11 settings.
- If Firefox is cleanly installed to the latest build, it will show only once in Default Apps in Windows and will be automatically set by default to the supported file types
Bug: Private Mode title is not properly updated when live language switching
Status: NEW
Priority: P3
Created: 2022-04-12 10:03:23+00:00
Resolved: 2023-06-05 15:30:53+00:00

**Note:**
This is a follow-up of Bug #1760825

**Environment:**
Firefox 100 beta 4, latest Nightly 101.0a1
Win 10 64-bit, OS X 11, Ubuntu 22.04

**Preconditions:**
user_pref("intl.multilingual.downloadEnabled", true);
user_pref("intl.multilingual.enabled", true);
user_pref("intl.multilingual.liveReload", true);
Install languages:
about:preferences /Language - Search More Languages/Select Language to add / Add.

**STR:**
1. Install a Firefox locale, en-us for example (autoset region not that relevant).
2. Locate languages and install a few languages
3. Open a new Private Window and several new tabs
4. Open about:preferences / Language.
5. Switch the language to anything previously added

**Actual results:**
Private mode tabs title is not modified for the tabs that were already opened when the language was changed. The tab title is localized for tabs opened afterwards.

**Expected results:**
The localized title is modified in Private windows, just like for Normal windows.
Bug: The pref for Firefox default PDF handler does not work as expected after Firefox update while it was manually set as default PDF handler before
Status: NEW
Priority: --
Created: 2022-04-12 10:44:07+00:00
Resolved: 2023-12-09 00:01:02+00:00

**Affected versions**
* Firefox 100.0b4
* Firefox 101.0a1

**Affected platforms**
* Windows 10 x64
* Windows 11 x64

**Steps to reproduce**
1. Older Firefox is installed (ex. 98.0b8) and is set as the default browser and PDF handler.
2. Launch Firefox and initiate the update.
3. Set browser.shell.setDefaultPDFHandler to true.

**Expected result**
* Enter the system defaults settings and see that Firefox is still set default to PDF as 
  well, the file type description is "Firefox PDF Document" and the new icon is applied.

**Actual result**
* In system settings Firefox is the default web browser but the file type description and 
   the associated icon hasn't changed (see attachment: after update 98 to 100.0b4.png).

**Regression range**
 * Can't search for a regression as Firefox will be updating to the latest version.
Bug: Live languages are not synced between profiles
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2022-04-12 13:18:54+00:00
Resolved: 2022-04-21 01:05:30+00:00

**Affected versions**
* latest Nightly 101.0a1
* Beta 100.0b4

**Affected platforms**
* Win 10 x64
* Ubuntu 18.04 x64
* macOS 11

**Steps to reproduce**
1. Launch Firefox on a profile A.
2. Launch a second instance of Firefox on a profile B.
3. In one of the browsers, from `about:preferences`, "Language" section , change the language to a difference one than default (e.g. Italian).
4. Perform a sync to both instances of Firefox.

**Expected result**
* The languages are synced between the Firefox profiles. 

**Actual result**
* The languages are not synced between the Firefox profiles. 

**Regression range**
* Not a regression, more like an implementation bug, since it can be reproduced after Live language reloading feature was implemented.
* The issue cannot be reproduce on Release 99.0.1, where the above feature is not landed yet.

**Additional notes**
-  This issue can be reproduced with some of the most used languages: en-US, de-DE,  fr-FR and zh-CN.
Bug: Non-ASCII characters in form fields missing/changed when printing PDF documents
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-04-12 13:22:48+00:00
Resolved: 2022-11-23 10:50:32+00:00

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

Steps to reproduce:

See the attached PDF document for a minimal test case. It's a word document saved as PDF. I've used the official Adobe Acrobat Pro to auto-detect form fields. The lower, broken field is a result of that automatic detection.
I've then deleted the auto-detected top field and copied the bottom one to result in the now working top field.


Actual results:

Entering any non-ascii character (I've tried with Umlauts ä ö ü and accented characters like é) and entering print preview shows these characters are missing (in the case of umlauts) or misrepresented (é turns into Ø) in the lower field. When entering the same characters in the top field, the characters are displayed correctly in print preview and printed correctly.


Expected results:

Form fields should be fillable and printable with non-ascii characters regardless whether the fields were auto-detected or produced by hand.
This problem regularly occurs with internal PDF forms for our company that users try to fill with Firefox.
The problem has shown up somewhere within the last year and still happens in today's Nightly. I'll try to produce a narrower regression range shortly.
It might be a font issue as alluded to in bug 1752545 but I'm not familiar enough with the structure of PDF files to make an educated guess.
Bug: The QR code from the "PB_FOCUS_PROMO" modal wrongly redirects to the "Firefox Klar" app even if the region is set to "US" and a Firefox en-US locale build is used
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-04-12 13:39:40+00:00
Resolved: 2022-04-27 20:08:37+00:00

**[Affected versions]:**
- Firefox Beta 100.0b4 - Build ID: 20220410195727
- Firefox Nightly 101.0a1 - Build ID: 20220412094307

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

**[Prerequisites]:**
- Have a Firefox en-US locale build installed.
- Have a new Firefox profile with the "browser.search.region" pref set to "US" in the "about:config" page.
- Have a device with a QR code scanner app installed.

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Open a new "Private Window" (Ctrl+Shift+P).
3. Click the "Download Firefox Focus" button.
4. Scan the modal's QR code and observe the behavior.

**[Expected result]:**
- You are redirected to the "Firefox Focus" app.

**[Actual result]:**
- You are redirected to the "Firefox Klar" app instead.

**[Notes]:**
- The modal's QR code redirects to the "https://mzl.la/3racU17" URL.
Bug: The "PB_FOCUS_PROMO" modal is not responsive if the browser is vertically or horizontally resized
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-04-12 14:31:14+00:00
Resolved: 2022-05-05 14:38:29+00:00

**[Affected versions]:**
- Firefox Nightly 101.0a1 (Build ID: 20220408094506)
- Firefox Beta 100.0b4 (Build ID: 20220410195727)

**[Affected Platforms]:**
- Mac 10.15.7
- Windows 10 x64
- Ubuntu 20.04 x64

**[Prerequisites]:**
- Have the latest Firefox Nightly/Beta 100 browser installed.
- Have a new Firefox profile.

**[Steps to reproduce]:**
1. Open the Firefox browser with the profile from prerequisites.
2. Open a Private Window.
3. Resize the browser vertically and horizontally to 25% of its width.
4. Observe the modal.

**[Expected result]:**
- All the elements from the modal are visible and displayed.
OR
- There are scrollbars available in order to scroll the modal to see all the elements.

**[Actual result]:**
- There are elements from the modal that are not visible and the modal cannot be scrolled.

[Notes]:
- Attached is a screen recording of the issue.
Bug: Since latest update I cannot get into my online banking
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-04-12 19:37:51+00:00
Resolved: 2022-05-03 14:37:39+00:00

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

Steps to reproduce:

Tried to sign into bank account. Also deleted cookies & cache.  I also called bank, they had no problems with their web-site.  I used Google Chrome and the pages load. Also no problem loading program on android table and phone.  
ecu.com


Actual results:

will not load the page of my bank.  says redirecting you to online banking, but does not bring page up. (Redirecting you to online banking is what usually comes up, but it then is caught up in a loop and will not load page)  


Expected results:

Online bank page should load
Bug: Since latest update I cannot get into my online banking
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-04-12 19:39:16+00:00
Resolved: 2022-04-13 06:18:24+00:00

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

Steps to reproduce:

Tried to sign into bank account. Also deleted cookies & cache.  I also called bank, they had no problems with their web-site.  I used Google Chrome and the pages load. Also no problem loading program on android table and phone.  
ecu.com


Actual results:

will not load the page of my bank.  says redirecting you to online banking, but does not bring page up. (Redirecting you to online banking is what usually comes up, but it then is caught up in a loop and will not load page)  


Expected results:

Online bank page should load
Bug: Unable to drag new bookmark from bookmark menu into Bookmarks Toolbar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-04-13 00:14:53+00:00
Resolved: 2022-05-12 14:32:40+00:00

**Steps to reproduce**

1. Go to a website
2. Click on star icon to bookmark page (make sure Bookmarks Toolbar is selected as the destination)
3. Open new tab (Bookmarks Toolbar is hidden except on new tab)
4. Click on double chevrons to open additional bookmarks menu
5. Attempt to drag and drop the most recent bookmark to a different spot in the Bookmarks Toolbar

**Expected behaviour**
Bookmark should be moved to new spot.

**Actual behaviour**
Nothing happens, as the new bookmark can not be dragged into new spot. Instead, the cursor moves normally without dragging anything.

**Notes**
You may be successful on the first attempt, but the bug may manifest on subsequent attempts.

Reproduced on: Firefox 99.0.1 (64-bit) macOS Big Sur (11.6)
Bug: start page is ignored
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-04-13 08:48:36+00:00
Resolved: 2022-04-13 15:32:28+00:00

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

Steps to reproduce:

Starting Firefox I


Actual results:

Startpage (https://www.startpage.com/) is ignored. Every time it starts wwith the page of the last usage.


Expected results:

 expect to start on the start page which is entered at Optioms: (https://www.startpage.com/).
Bug: [New users] The “about:welcome” page is broken on Firefox AR locale if the Central Kurdish OS language is set
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-04-13 11:52:42+00:00
Resolved: 2022-04-18 14:20:23+00:00

**[Affected versions]:**
- Firefox Beta 100.0b5 (Build ID: 20220412185818)

**[Affected Platforms]:**
- Windows 10 x64
- Ubuntu 20.04 x64

**[Prerequisites]:**
- Have the latest Firefox Beta 100 browser, ar locale installed/extracted.
- Have the OS language set to Central Kurdish.
- Have a new Firefox profile.

**[Steps to reproduce]:**
1. Open the Firefox browser with the profile from prerequisites.
2. Observe the “about:welcome” page.

**[Expected result]:**
- The “about:welcome” page is correctly displayed.

**[Actual result]:**
- The “about:welcome” page is broken and contains only the background image.

**[Notes]:**
- This issue is not reproducible on Nightly builds.
- I didn’t manage to reproduce this issue on macOS.
- This issue is still reproducible after restarting the browser.
- Attached is a screen recording of the issue: [link](https://drive.google.com/file/d/15_a0iIfQbOM6sM37qlaJAFlFNUr-H2WC/view?usp=sharing).
Bug: can't drag and drop a pdf file into outlook on the web window
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-04-13 15:04:09+00:00
Resolved: 2022-04-13 15:09:38+00:00

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

Steps to reproduce:

I open a new email message
click on a pdf file in file explorer
drag over to new email message


Actual results:

get the attached image of a circle with a red line through it, not allowing me to attach the pdf file to the new email message.



Expected results:

up until last week, it would attach the file to the new email message.