av9ash/GitBugs huggingface dataset:
Bug: Firefox is closed if I only left Downloads window to downloading a large file
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-12-10 01:47:29+00:00
Resolved: 2020-12-10 14:40:35+00:00

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

Steps to reproduce:

I am downloading a large file from rapidgotor.net, I close all bowser tab and only left Downloads window open


Actual results:

the Downloads window close after a while (may be around after 1 and a half hour to two hour) and cause all Firefox process ended, the download is Interrupted


Expected results:

the Downloads window will keep Firefox process open and continues download the file until manual close it, then all Firefox process ended
Bug: [@ mozilla::a11y::GeckoTextMarker::CreateAXTextMarker] - Firefox 83.0 Crash Report
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-12-10 03:06:28+00:00
Resolved: 2024-06-07 16:21:17+00:00

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

Steps to reproduce:

https://crash-stats.mozilla.org/report/index/bc26cbdc-0450-4204-bead-48b910201210


Actual results:

https://crash-stats.mozilla.org/report/index/c79e8b71-a96f-4a38-bce1-08a0c0201210


Expected results:

Fx should not crash
Bug: [@ HyperTextIterator::NormalizeForward] - Firefox 83.0 Crash Report - Report ID: 6222bdf4-8eb7-4e4f-9730-581570201210
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-12-10 03:08:22+00:00
Resolved: 2024-06-07 16:20:04+00:00

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

Steps to reproduce:

https://crash-stats.mozilla.org/report/index/e35af05a-8d1b-4caa-9bc6-9dbeb0201117


Actual results:

https://crash-stats.mozilla.org/report/index/6222bdf4-8eb7-4e4f-9730-581570201210


Expected results:

Fx should not crash
Bug: [@ HyperTextIterator::NormalizeForward] - Firefox 82.0.2 Crash Report - Report ID: 5a216d5d-04ae-491d-a869-110500201105
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-12-10 03:12:29+00:00
Resolved: 2024-06-07 16:20:44+00:00

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

Steps to reproduce:

[@ HyperTextIterator::NormalizeForward] - Firefox 82.0.2 Crash Report - Report ID: 5a216d5d-04ae-491d-a869-110500201105


Actual results:

https://crash-stats.mozilla.org/report/index/5a216d5d-04ae-491d-a869-110500201105


Expected results:

Fx should not crash
Bug: Show better information when add-ons block downloads (e.g. .txt files from some sites when uMatrix is installed)
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-12-10 03:41:17+00:00
Resolved: 2020-12-16 04:05:14+00:00

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

Steps to reproduce:

Hi guys.

First time filing a bug report so hopefully what I've got here is useful and helpful. It's a repeatable bug, and works fine in other browsers so that's a good start I guess. This bug has persisted for some time, and since it hasn't yet been resolved I thought it was time I filed a bug report.

The issue is I am unable to download .txt files from this website, but I'm pretty sure it affects other websites as well, this is just one I access frequently:

https://support.magicard.com/solution/enduro-firmware/

The binary file download links work fine, and I can view the .txt document in preview mode just fine but I'm unable to save it at all, either from the context menu or from the save as menu when previewing.


Actual results:

If I try from the context menu "Save Link As" option Firefox just immediately says "The download cannot be saved because an unknown error occurred. Please try again."

Trying from the "Save As" menu when previewing just results in a failed download in the download window.


Expected results:

Expected behavior is obviously that the .txt file successfully downloads.
Bug: about:logins content behind Remove All modal moves left-right from arrows
Status: NEW
Priority: P3
Created: 2020-12-10 07:39:56+00:00
Resolved: 2020-12-10 20:47:36+00:00

**Affected versions**
* 85.0a1 (2020-12-09);

**Affected platforms**
* macOS 10.15, Windows 10, Ubuntu 20;

**Steps to reproduce**
1. Launch Firefox, add at least 2 user login-password(s) access about:logins
2. Either zoom in or resize browser so it takes up half of the screen only;
3. Click on the modal (optional click on the Yes, remove these logins...);
4. Press the TAB key to get one of the  Cancel/Remove all button in focus;
5. Press the left-right key on keyboard;

**Expected result**
* focus moves between the buttons;

**Actual result**
* background content moves left right, focus remains on the same button;

**Regression range**
* not a regression, visible with addition of the modal;

**Additional notes**
* attached recording with the issue;
* S4 as suggested severity since it's somewhat of an edge case and the impact is minimal;
* main point would be that at least for as long the focus is on the 2 buttons, the background scrolling to be disabled - making it more of an enhancement.
Bug: about:addons Focus ring remains on bottom buttons
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-12-10 08:09:58+00:00
Resolved: 2020-12-17 14:58:46+00:00

**Affected versions**
* 85.0a1 (2020-12-09), 84.0;

**Affected platforms**
* macOS 10.15, Windows 10, Ubuntu 20;

**Steps to reproduce**
1. Launch Firefox, access about:addons
2. Click on the Nightly Preferences button;
3. Click on the Extensions and themes button;

**Expected result**
* no glitches occur;

**Actual result**
* Nightly Preferences and Add-ons Support buttons have focus rings (right side is cut-off as well making it stand out even more);

**Regression range**
* First bad: 2020-05-16;
* Last good: 2020-05-15;
* Pushlog: [URL](https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=882de07e4cbe31a0617d1ae350236123dfdbe17f&tochange=4221f87da7fe9ecdb1a7ceda3967a7cc0acbf942)
* Potential regressor: 1638127

**Additional notes**
* attached recording with the issue;
* S4 as suggested severity.
Bug: about:addons Add White icon on Firefox Screenshots Shortcuts  for dark theme
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-12-10 08:50:52+00:00
Resolved: 2020-12-10 15:00:51+00:00

**Affected versions**
* 84.0, 85.0a1 (2020-12-09);

**Affected platforms**
* Windows 10, macOS 10.15, Ubuntu 20;

**Steps to reproduce**
* OS - Firefox theme(s) set to dark;
1. Launch Firefox, access about:addons
2. Click on the Extensions section;
3. Click on the Cogwheel on the right side;
4. Click on the Manage Extensions button;

**Expected result**
* Icon would be visible(white) in contrast;

**Actual result**
* icon is black - on dark-grey background it not visible;

**Regression range**
* First bad: 2019-05-31;
* Last good: 2019-05-30;
* Pushlog: [URL](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e09471d136599b68f40f6bb9ec7fcc419732948e&tochange=a73077366144b9699555a1c6f96507d3f353be9b);
* Potential regressor: mozregression points towards 1553416; thus it's not a regression, was implemented like this with addition in the section;

**Additional notes**
* attached screenshot to illustrate the issue;
* S4 as suggested severity since the impact is minimal.
Bug: default audio
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-12-10 08:52:59+00:00
Resolved: 2020-12-18 07:53:26+00:00

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

Steps to reproduce:

Open any audio on Firefox (whatever the way)


Actual results:

The audio is redirected on an output that Firefox has personally decided


Expected results:

It should output the audio on the actual default OS output
Bug: renderInteractiveForms - Issue printing
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-12-10 10:16:28+00:00
Resolved: 2021-10-18 13:11:32+00:00

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

Steps to reproduce:

With the last release of Firefox the support for PDF Form Filling was enabled by default (pdfjs.renderInteractiveForms = true). There are now rendering issues and printing issues with the text size / font size.

I have attached several screenshots, PDF and the original PDF-Document.

Steps:
1. Default firefox settings: pdfjs.renderInteractiveForms = true
2. Open attached "Original_Document.pdf" in Firefox 83.0 (Windows 10 Pro 20H2, 100% dpi scaling)
3. Print the document or use "Microsoft Print to PDF"
5. keep the window/tab

5. Change => pdfjs.renderInteractiveForms = false
6. Open again in new tab the "Original_Document.pdf"
7. Compare rendering on screen with previous tab (renderInteractiveForms = true) -> font size is different
8. Print the document or use "Microsoft Print to PDF"
9. compare both printed versions =>  the first document (renderInteractiveForms = true) as a very large text / font size, compare to second print (expected result)

10. Open "Original_Document.pdf" with Chrome / Acrobat Reader
11. Print document for both documents => equal to second print ( pdfjs.renderInteractiveForms = false) == expected result

I have attached screenshots and printed results (Microsoft Print to PDF) for all versions.


Actual results:

Some textfields are rendered with a different size / printed with a very high size

actual result (pdfjs.renderInteractiveForms = true):
1. Firefox_fillable.png
2. Firefox_fillable_Printed.pdf


Expected results:

Expected (Firefox => pdfjs.renderInteractiveForms = false):

Firefox_fillable_disabled.png
Firefox_fillable_disabled_Printed.pdf
Acrobat_reader.png
Acrobat_reader_printed.pdf
Chrome.png
Chrome_printed.pdf
Bug: Private mode offers switch-to-tab option for normal-mode open sites (must be top sites)
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-12-10 11:14:33+00:00
Resolved: 2021-02-12 21:22:09+00:00

##### [Suggested Severity:] 
S3

##### [Description:]
When a site is opened in normal mode and is in topsites, the private window will offer switch-to-tab option when private mode topsites are loaded.

##### [Environments:]
Windows 10, Mac 10.14.6, Ubuntu 20.04
85.0a1 2020-12-09
84.0 2020-12-07
83.0
78.5.0esr




##### [Steps:]
1. (optional)New profile.
2. Open a new tab, select and load one of the top sites.
3. Open a private window and click the addressbar.

##### [Actual Result:]
The top-site opened in normal window is shown with the switch-to-tab option, even thought we're in private mode. Clicking on it does nothing.

##### [Expected Result:]
There is no switch-to-tab option in private window.

##### [Note:]
1. The above scenario doesn't reproduce if the site is not in the top-sites.
2. After the bug 1659752 fix, this issue is more visible.
Bug: Middle click search broken in search-bar
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-12-10 12:30:18+00:00
Resolved: 2020-12-17 09:26:03+00:00

##### [Suggested severity:]
S3

##### [Environment:]
Windows 10
Fx 85.0a1 2020-12-10

##### [Description:]
Using middle click on search bar/address bar suggestions should open the search +search results in a new tab.

##### [Steps:]
1. Open firefox.
2. Open about:preferences#search and enable search bar.
3. Input a few chars into search bar to generate search suggestions.
4. Middle click on one of the search suggestions.

##### [Actual Result:]
Nothing happens.

##### [Expected Result:]
A new tab opens with the search + search results list.

##### [Regression Range:]
Found commit message:
Bug 1680735 - Rename SearchTelemetry to SearchSERPTelemetry. r=daleharvey
Bug: Copying is not possible from the context menu after swapping a docshell (detaching a tab into its own window)
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-12-10 12:55:29+00:00
Resolved: 2023-03-09 11:13:32+00:00

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

Steps to reproduce:

- A second window is opened next to the current window (e.g. by moving an already open tab out of the current window).

- highlight text,
- right mouse button (context menu opens) and
- at the moment copy is not clickable / grayed out.

at camp-firefox we found out that when the window loses focus and we return, the "copy" is clickable


Actual results:

After opening the window, copy is in context menu remains grayed out -> unclickable


Expected results:

"copy" should have been clickable
Bug: If I click out of the adress bar the search mode is exited
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-12-10 13:09:46+00:00
Resolved: 2020-12-10 16:16:26+00:00

**[Sugested Severity:]**
S3

**[Description:]**
when I'm on search bar, initialized by tab to search, and I click out of the search bar or change applications, the search mode is lost.

**[Steps:]**
1. Open Firefox with a new profile.
2. Click on the search bar
3. Type @g and press tab (google search mode is started)
4. Click out of the address bar

**[Actual result:]**
Search mode is lost and only @g is shown in the address bar
 
**[Expected result:]**
When you are in search mode and click out of the address bar, we use a lighter version of the search engine indicator. It's meant to move into the background like the rest of the address bar

**[Notes:]**
This is a regression. It does not happen on release because on release I can't do step 3. I can also reproduce it with tab to search. I will do the mozregression later on.
Bug: Intermittent TEST-UNEXPECTED-TIMEOUT | browser/components/preferences/tests/browser_search_within_preferences_command.js | application timed out after 370 seconds with no output
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2020-12-10 14:45:14+00:00
Resolved: 2021-01-05 11:42:18+00:00

**Filed by:** archaeopteryx [at] coole-files.de
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=324131280&repo=try
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/WA2DTfOUS3mlWj8TtJPH6w/runs/0/artifacts/public/logs/live_backing.log

---
```
[task 2020-12-10T11:48:16.061Z] 11:48:16     INFO - TEST-START | browser/components/preferences/tests/browser_search_within_preferences_command.js
[task 2020-12-10T11:54:29.854Z] 11:54:28     INFO - Buffered messages logged at 11:48:16
[task 2020-12-10T11:54:32.888Z] 11:54:31     INFO - Entering test bound 
[task 2020-12-10T11:54:34.665Z] 11:54:33     INFO - Buffered messages finished
[task 2020-12-10T11:54:37.641Z] 11:54:36    ERROR - TEST-UNEXPECTED-TIMEOUT | browser/components/preferences/tests/browser_search_within_preferences_command.js | application timed out after 370 seconds with no output
```
Bug: Startup Crash in [@ mozilla::ErrorLoadingSheet]
Status: NEW
Priority: --
Created: 2020-12-10 15:16:33+00:00
Resolved: 2025-01-11 16:03:52+00:00

Crash report: https://crash-stats.mozilla.org/report/index/74d718ab-c6a3-4599-b769-9bd7c0201210

MOZ_CRASH Reason: ```LoadSheetSync failed with error 80520012 loading built-in stylesheet 'chrome://global/content/xul.css'```

Top 10 frames of crashing thread:
```
0 xul.dll mozilla::ErrorLoadingSheet layout/style/GlobalStyleSheetCache.cpp:530
1 xul.dll mozilla::GlobalStyleSheetCache::LoadSheet layout/style/GlobalStyleSheetCache.cpp:565
2 xul.dll mozilla::GlobalStyleSheetCache::LoadSheetURL layout/style/GlobalStyleSheetCache.cpp:510
3 xul.dll mozilla::GlobalStyleSheetCache::XULSheet layout/style/UserAgentStyleSheetList.h:40
4 xul.dll mozilla::GlobalStyleSheetCache::GlobalStyleSheetCache layout/style/GlobalStyleSheetCache.cpp:239
5 xul.dll static mozilla::GlobalStyleSheetCache::Singleton layout/style/GlobalStyleSheetCache.cpp:460
6 xul.dll mozilla::dom::Document::FillStyleSetUserAndUASheets dom/base/Document.cpp:2766
7 xul.dll mozilla::dom::Document::CreatePresShell dom/base/Document.cpp:6150
8 xul.dll nsDocumentViewer::InitPresentationStuff layout/base/nsDocumentViewer.cpp:768
9 xul.dll nsDocumentViewer::InitInternal layout/base/nsDocumentViewer.cpp:974
```
I've encountered this startup crash several times on Windows 10 x64, using Firefox 78.6.0 ESR, latest Nightly 85.0a1 and Firefox 84 RC. 

I've tested on machines with Cisco AMP for Endpoints (7.2.11.11804) - our default antivirus on Softvision machines, and this antivirus seems to detect the omni.ja file as a corrupt file and blocks it. 

On machines with other antiviruses (Bitdefender, Windows Defender), everything looks good and no crash occur. 

**Suggested severity: S1**
Bug: [Experiment] Attribution request is not sent for sponsored top sites that have been pinned
Status: RESOLVED
Priority: P2
Resolution: WONTFIX
Created: 2020-12-10 15:49:32+00:00
Resolved: 2020-12-15 17:35:25+00:00

**[Notes]:**
- Sometimes moving the top site will cause the ping to be sent at click from that moment - the exact trigger has not been determined.
- Similarly, it has been observed that the ping is sent with a delay.

**[Affected versions]:**
- Firefox Beta 84.0 (Build ID: 20201207203640)

**[Affected Platforms]:**
- Windows 10
- macOS 10.15
- Linux Mint 20

**[Prerequisites]:**
- Be enrolled in the Treatment branch of one of the TopSites Launch Phase 3 experiments.
- Have the Browser Console displayed and XHR enabled.
 
**[Steps to reproduce]:**
1. Open a new tab.
2. Hover a Sponsored top site (Amazon/eBay) and click on the “…” button to open the context menu.
3. Click the “Pin” option.
4. Click on the tile.
5. Observe the Browser Console.

**[Expected result]:**
-  The “https://topsites.services.mozilla.com/cid/amzn_2020_a1” ping is sent at click on the tile.

**[Actual result]:**
-  The “https://topsites.services.mozilla.com/cid/amzn_2020_a1” ping is **not**  sent at click on the tile.

**[Additional Notes]:**
- The issue is also reproducible if the tile is moved (and as such, pinned).
- Attached is a recording of the issue.
Bug: Update Picture-in-Picture documentation diagram to reflect PictureInPictureLauncher changes
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-12-10 17:21:51+00:00
Resolved: 2020-12-11 04:53:25+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Bug: Prevent superfluous PictureInPictureParent actors from being associated with each tab
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-12-10 17:23:31+00:00
Resolved: 2021-01-21 03:25:49+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Bug: "Restore Default Search Engines" button removes tabs, bookmark and history's search shortcuts from the list
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-12-10 19:21:50+00:00
Resolved: 2021-01-06 18:07:53+00:00

**[Sugested Severity:]**
S3

**[Description:]**
when I remove search shortcuts in a particular order and then press "Restore Default Search Engines", Bookmarks, Tabs, and History are removed forever.

**[Steps:]**
1. Open Firefox with a new profile.
2. Go to about:preferences#search
3. Remove two search shortcuts immediately above Bookmarks
4. Remove the rest of bookmarks from top to bottom. It's important to press remove twice or thrice after removing all possible search engines.
5. Hit Restore Default Search Engines

**[Actual result:]**
Search engines are restored but bookmarks, tabs, and history are lost forever
 
**[Expected result:]**
Search engines are restored and bookmarks, tabs, and history are kept
Bug: 'Don’t enable HTTPS-Only' shouldn't require restart
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-12-10 19:54:44+00:00
Resolved: 2022-07-07 18:00:00+00:00

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

Steps to reproduce:

ticked 'Enable HTTPS-Only in all windows'
in some pages the option to load HTTP version isn't offered, so
ticked 'Don’t enable HTTPS-Only' 


Actual results:

 HTTP adressses keep appearing as HTTPS, making imposible to see some sites, i tried deleting cookies, deleting site preferences, in about:config disabling HTTPS-Only ...
i had to restart


Expected results:

tick 'Don’t enable HTTPS-Only' shouldn have immediat effect, not require a restart
Bug: about:restartrequired pages don't get restored properly from sessionstore now
Status: NEW
Priority: --
Created: 2020-12-10 20:12:44+00:00
Resolved: 2020-12-11 12:16:57+00:00

Rough STR (just based on my usage, not sure exactly):
 1. Have Firefox configured to "restore previous session" at startup, in your Firefox `about:preferences` page.
 2. Be running an out-of-date version of Nightly (e.g. yesterday's nightly).
 3. Start another instance of Firefox in the background with a fresh profile:
```
 mkdir /tmp/foo; firefox -no-remote -profile /tmp/foo
```
 4. Allow a Firefox update to install (not sure exactly how/when this happens)
 5. Navigate around / open tabs / etc. in your original instance of Firefox, until one of them shows an `about:restartrequired` page ("Sorry. We just need to do one small thing to keep going.")
 6. Restart Firefox.

EXPECTED RESULTS:
The `about:restartrequired` tab should now load the actual content that it was trying to load.

ACTUAL RESULTS:
The `about:restartrequired` page gets restored *still showing the error page* (even though now there's no update staged & no issues that require a restart).  The URL bar for this tab now shows something like `about:restartrequired?e=restartrequired&u=about%3Ablank&c=UTF-8&d=%20`, where the "u=..." contains a URL-encoded version of the original URL.

I think this is a regression - I perform something like the STR (and hit this restartrequired page) fairly frequently, and I only started noticing this tab-failing-to-restore issue in the last month or so.
Bug: Page content contains a one-pixel line from browser chrome
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-12-10 22:48:19+00:00
Resolved: 2020-12-18 15:59:12+00:00

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

Steps to reproduce:

Nothing, it's present everywhere


Actual results:

On any and every page in Firefox, there is a one-pixel horizontal line of browser chrome visible in the content of the page.



Expected results:

The page content should not include any chrome.

You can see it clearly by setting the theme to the included Firefox AlpenGlow. You'll notice a line of blue and pink under the toolbar, in the area of the page content. If you hide the toolbar (with CSS or opening a chromeless popup window), the line is still visible because it's actually in the page content itself.