av9ash/GitBugs huggingface dataset:
Bug: Setting browser.urlbar.maxRichResults to 0 introduces a delay when searching
Status: UNCONFIRMED
Priority: P3
Created: 2021-06-13 07:34:37+00:00
Resolved: 2024-03-23 03:48:45+00:00

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

Steps to reproduce:

When browser.urlbar.maxRichResults is set to 0 on two different computers both computers introduced a delay when executing a search from the URL bar. The setting was toggled back and forth between 0 and default (10) to compare the speed on both computers. On one computer, the delay was shorter, ~300ms; on the other, ~600ms. The delay was consistent across various searches. The default search engine has no bearing either. I tried DuckDuckGo, Google and Bing. The delay was the same (for each computer) regardless of what was searched. I searched simple keywords like "test", "cats" and "dogs" and longer searches like "peanut butter and jelly" in addition to URLs, I tested www.google.com and www.duckduckgo.com, among others. The delay was consistent.


Actual results:

Both computers introduce a delay when browser.urlbar.maxRichResults is set to 0. The delay occurs after the search is entered. The browser does not immediately try to access the typed webpage/keywords, but instead has a brief delay, and then searches. Setting browser.urlbar.maxRichResults back to default (or anything greater than 0) removes the delay. The delay does not occur if a search is performed with Ctrl+Enter, presumably because the browser is not having to decide if the search is a keyword or a URL (it is being told it is a URL in that case). Because of this, I believe the delay is caused by the browser having to decide if a search is a keyword or URL since the rich results field is disabled. Usually, when the rich field is on by default, the predicted top result is highlighted and pressing "Enter" on it means the browser is being told what it is and not having to decide. So when disabled, it is instead having to decide after the fact, causing the delay. 


Expected results:

Setting browser.urlbar.maxRichResults to 0 should not have an impact on search speed. Although it is considered a tweak and not a default setting, it is the only method to completely prevent the rich results field from displaying. There are situations where the rich results field is not desired so it is necessary to be able to disable it this way, and doing so should not have an impact browsing performance. I believe something will have to be done with how the browser decides something entered is a search or a URL without causing delays.
Bug: Two entries of "Manage Bookmarks" on the bookmark toolbar menu
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-13 08:53:59+00:00
Resolved: 2021-06-14 08:34:39+00:00

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

Steps to reproduce:

See where it says "Manager Bookmarks" twice on the screenshot? A bit redundant, no? This is on both 89 and 91 on Windows.

Peace!
Bug: Download manager shows confusing number of downloads string
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-06-13 14:17:32+00:00
Resolved: 2021-11-17 13:17:56+00:00

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

Steps to reproduce:

Downloading several files at the same time.


Actual results:

Download manager said I had only 4 downloads going, when I actually had 9. (The image shows 5, but there were 9 total ongoing. When some finish, the wrong number is still shown.


Expected results:

Download manager should report the correct number of ongoing downloads.
Bug: Firefox 89 Introduced Confusing URL / Search / Tab / Home screen behaviors
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-13 14:23:22+00:00
Resolved: 2021-06-13 17:33:49+00:00

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

Steps to reproduce:

This is a set of confounding issues related to ill-conceived user interface design.

1)  On the home screen with new Firefox launch, when I go to the "Search with DuckDuckGo or enter address" text box, and start typing, it moves me to a box with the "search" icon (where the current URL usually is at?).  This is quite jarring, also there's much less screen realestate there as opposed to the main text area where I wished to type my search.

2) The current tab shows up in a style where it looks like it could be a text entry box.  When you click on it, your cursor jumps to the second "Search" text area, which also has a search box like the URL.  This search text box has room for about 10 characters to be visually seen, which is quite useless.  It's also jarring behavior.

3) I've never been fond of a second "Search" text box, but it's there wasting space, and now seems to be totally redundant with the URL box.  Amazingly enough, when you type there from a new screen... it even has the search icon.   


Actual results:

1) It moved my cursor from the "Search with duckduckgo or enter address" box to the main URL text area.  Don't move my selection please.  If I clicked there, that's where expect to be able to type. 

2) It moved my cursor to the second search area, and not the URL search area, which is equally unexpected.  If the tab looks editable, it should be editable.

3) It's confusing if or what is the distinction between URL & Search bar, and this confusion is only aggravated by having the same magnification glass icon.


Expected results:

1)  You should let me type in my search in the search box on the home screen... or just remove the search box entirely.  Putting it there and using it as a button is confusing.

2) The active tab should -not- look as if it's editable text area.  This is confusing.

3) If you're going to conflate search and URL text entry, you should remove the search box.  Moreover, if you're going to keep them in the same bar, they certainly shouldn't share the same icon.
Bug: ALT-B <right-click bookmark> P is no longer the keyboard shortcut to change the properties of a bookmark
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-06-13 16:26:43+00:00
Resolved: 2021-06-22 14:29:34+00:00

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

Steps to reproduce:

open firefox (by any method)
click ALT-B (using keyboard)
right-click bookmark (using mouse)
type P (using keyboard)


Actual results:

Nothing


Expected results:

The properties of the bookmark should have opened in the Bookmark editor.


What did happen is that someone who NEVER USES KEYBOARD SHORTCUTS changed something again, for no reason at all.
Bug: Difficulty in accessing modem router webUI(192.168.X.X).
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-13 17:18:16+00:00
Resolved: 2021-06-29 19:49:49+00:00

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

Steps to reproduce:

To reproduce, follow steps carefully.
1. get yourself a Huawei Modem. Mine was Globe AT HOME (Huawei B312-939)
2. go to the IP of your modem
3. Click login-I can feel the struggle here.
4. Login-Having trouble on typing.


Actual results:

Cannot LOGIN to my modem. Need to use another browser temporary while you are fixing bugs


Expected results:

I could just login with admin and admin on the webpqge 192.168.254.254 (aka. 192.168.8.1)
Bug: ebay top menu disappeared
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-13 17:32:34+00:00
Resolved: 2021-06-14 06:01:16+00:00

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

Steps to reproduce:

Went to ebay in FF


Actual results:

Top menu disappeared in firefox but appears in chrome and Edge


Expected results:

Top horizontal menu bar for ebay should have appeared as usual.  this is only happening in 89.0
Bug: Web search in Firefox start page jumps to URL bar even when URL bar search suggestions off
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-13 20:52:06+00:00
Resolved: 2021-06-13 22:37:54+00:00

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

Steps to reproduce:

Web search on the Firefox start page jumps to the URL bar now. Web search is not a history search - it is presumably called web search for a reason. When I disable URL bar search suggestions (so I can only display URL history), web search still sends me to the URL bar and shows only URL history vs showing me search suggestions. It's actually not web search box now but just a 2nd URL/address bar.


Actual results:

Starting to type in the Web search box on the Firefox start page takes me to the URL bar where only URLs from history are suggested when search suggestions are turned off on the address bar. It should show me search suggestions from the web just as it used to regardless of settings for URL bar.


Expected results:

It should show search suggestions from the web regardless of what settings I've made on the URL/address bar. I use URL bar for history searching. I use a search box for search suggestions. Why offer a web search box on the home page if you're just going to punt people to the URL bar anyway? You should call it what it is - a 2nd URL bar in a different location on the screen. Jumping to the new search box on the toolbar would be better than current behavior but even then, why offer the big search box with nice big fonts if you're going to just move people somewhere else on the screen? Buggy behavior and serious loss of usability.
Bug: downloading multiple files not accessible
Status: UNCONFIRMED
Priority: P3
Created: 2021-06-14 06:48:28+00:00
Resolved: 2021-09-17 10:57:22+00:00

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

Steps to reproduce:

went to a link of a zoom meeting recorded in the cloud -- sorry I cannot share the exact link.  clicked on download multiple files link using Jaws 2021 screen reader May update. 


Actual results:

I could only access one of the files.  I could not access the pop-up for the other two files.


Expected results:

Using the keyboard, I should be able to access the pop-ups for the other two files -- even hitting save on the first file did not work for giving access to the other two files.
Bug: 6.04 - 3.32% tresize / tresize + 2 more (Linux) regression on Tue June 8 2021
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-06-14 07:14:34+00:00
Resolved: 2023-11-03 09:39:04+00:00

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

### Regressions:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 6% | tresize [(docs)](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tresize) |  | linux1804-64-shippable-qr | e10s stylo webrender | 20.65 -> 21.89 |
| 6% | tresize [(docs)](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tresize) |  | linux1804-64-shippable | e10s stylo | 18.48 -> 19.56 |
| 5% | tresize [(docs)](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tresize) |  | linux1804-64-shippable | e10s stylo | 18.51 -> 19.48 |
| 3% | tresize [(docs)](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tresize) |  | linux1804-64-shippable-qr | e10s stylo webrender-sw | 20.70 -> 21.39 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=30348), 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: 2.92% tp5n nonmain_normal_fileio (Windows) regression on Tue June 8 2021
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-14 07:18:44+00:00
Resolved: 2021-07-01 06:27:44+00:00

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

### Regressions:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 3% | tp5n [(docs)](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tp5n) | nonmain_normal_fileio | windows10-64-shippable-qr | e10s stylo webrender | 671,574,349.75 -> 691,192,809.67 |
### Improvements:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 9% | displaylist_mutate [(docs)](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#displaylist-mutate) |  | windows10-64-shippable-qr | e10s stylo webrender | 2,697.32 -> 2,451.65 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=30322), 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: PgUp works like Home, arrows do not work
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-14 07:52:07+00:00
Resolved: 2022-05-09 11:58:54+00:00

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

Steps to reproduce:

On some sites, navigation with cursor keys is broken. Paging up in a long page brings at the top.


Actual results:

Open a page, like https://en.wikipedia.org/wiki/Memory_paging. Pressing PgDn does not scroll before a clic inside the content area. After that, repeatedly paging up and down, scrolling down from the top scrolls one line first, one page after.

Open a page at www.ilpost.it. Scrolling down has the same incorrect behavior, while PgUp, or arrow up, brings the page home, no matter where you are. 


Expected results:

paging should be active when page loads and should behave as expected.
Bug: There is no date format validation on pdf
Status: NEW
Priority: P3
Created: 2021-06-14 08:57:28+00:00
Resolved: 2022-03-09 23:46:09+00:00

Tested with:
Nightly 91.0a1 (2021-06-13)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch firefox
2. Open the following pdf: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033
3. Go to "From"  and "To" date fields and input a wrong date format as "10-2021-21"

Actual result:
"From"  and "To" date fields accepts wrong format.

Expected result:
"From"  and "To" date fields should accept only valid date format(yyyy-mm--dd) as in Adobe Reader.
Bug: [XFA] PDF cannot be validated or cleared
Status: NEW
Priority: P3
Created: 2021-06-14 09:04:57+00:00
Resolved: 2022-02-11 17:00:01+00:00

Tested with:
Nightly 91.0a1 (2021-06-13)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch firefox
2. Open the following pdf: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033
3. Click on the "Validate" , "Clear form" and "Clear Section"buttons.

Actual result:
PDF is not validated/cleared(form/section).

Expected result:
PDF should be validated/cleared(form/section) as in Adobe Reader.
Bug: Cannot see Barclays bank home page after login
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-14 09:11:34+00:00
Resolved: 2021-07-01 11:01:02+00:00

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

Steps to reproduce:

Login into Barclays on-line by putting in surname & membership No. Then put in pin sentry details.
After login it should take you to home page where you see your accounts, all you get is a blank page.
I can log in with other browsers such as Bing or Chrome
It has been like like this for a number of months now.


Actual results:

After entering required security you cannot see the accounts screen, it presents just a blank page


Expected results:

You should get access to your bank account details
Bug: PDF is empty after downloading a file with input data
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-06-14 09:42:50+00:00
Resolved: 2021-07-08 12:06:42+00:00

Tested with:
Nightly 91.0a1 (2021-06-13)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch firefox
2. Open the following pdf: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033
3.  Input data into the input fields.
4. Save the document with the input data by clicking the "Download" button or using shortcut CTRL+S.

Actual result:
PDF is empty. No input data are saved.

Expected result:
PDF should be saved with input data.
Bug: All text should be displayed on print if text is too long on the field
Status: VERIFIED
Priority: --
Resolution: WONTFIX
Created: 2021-06-14 10:08:04+00:00
Resolved: 2021-07-08 11:10:45+00:00

Tested with:
Nightly 91.0a1 (2021-06-13)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch firefox
2. Open the following pdf: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033
3.  Input a long text into the text fields from "BACKGROUND INFORMATION" section
4. Print PDF by clicking  on "Print" icon or using the shortcut CTRL+P. 

Actual result:
Only a part of the message from text field is visible on print and the last part of the text is cut off.

Expected result:
All message from text field should be visible on print.
Bug: Text field should have a limit of chars
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-06-14 10:22:37+00:00
Resolved: 2021-07-08 11:12:56+00:00

Tested with:
Nightly 91.0a1 (2021-06-13)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch firefox
2. Open the following pdf: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033
3.  Input a long text into the text fields from "BACKGROUND INFORMATION" section.

Actual result:
Text fields has no limit of chars.

Expected result:
Text fields should have a limit of chars as in Adobe Reader.
Bug: Restart required almost on every new tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-14 11:37:50+00:00
Resolved: 2021-06-14 18:36:31+00:00

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

Steps to reproduce:

Load a page in a new tab.


Actual results:

Not sure, about:restartrequired occurs in a geometric progression: sometimes after 1-2, else 6-8 new tabs loaded and closed separately. Every new instance has the same crash report. Happens both on firefox-esr 78 and firefox 88-89, either downloaded standalone, installed via apt or sandboxed with snap.

Most common errors:

[Parent 9968, Main Thread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file ./ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 19
###!!! [Parent][MessageChannel] Error: (msgtype=0x210093,name=PBrowser::Msg_LoadRemoteScript) Channel error: cannot send/recv

... and always ends with:
###!!! [Parent][MessageChannel] Error: (msgtype=0x21006F,name=PBrowser::Msg_UpdateDimensions) Channel error: cannot send/recv
Bug: Switching mozilla accounts in firefox does not clear previous settings/bookmarks/passwords
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-14 13:35:38+00:00
Resolved: 2021-06-16 23:04:18+00:00

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

Steps to reproduce:

Two firefox accounts

Log into one account, wait for all the settings/bookmarks/passwords to load, then log out and log into the other account


Actual results:

My settings didn't chane, I still had all the bookmarks/passwords from the previous account


Expected results:

All the settings (bookmarks/passwords/ect) from the previous account should be reset and the settings from the new account should be loaded.
Bug: Text and radio buttons are overlapping on pdf printing from RTL build
Status: NEW
Priority: P3
Created: 2021-06-14 14:22:02+00:00
Resolved: 2022-01-28 14:42:07+00:00

Tested with:
Nightly 91.0a1 (2021-06-13)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch RTL build
2. Open the following pdf: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033
3.  Check few "Yes" radio buttons
4. Print PDF by clicking  on "Print" icon or using the shortcut CTRL+P. 

Actual result:
Radio buttons and text are overlapping.

Expected result:
Text and radio buttons should be properly displayed
Bug: Lines and text are missing  on high contrast
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2021-06-14 15:19:49+00:00
Resolved: 2023-06-02 15:21:39+00:00

Tested with:
Nightly 91.0a1 (2021-06-13)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:
1. Turn on the Hight Contrast(White/Black) on your system
2. Launch firefox
3. Open the following pdf: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033

Actual result:
Few lines of the table and date format text of the form are missing with hight contrast white. 
On High Contrast Black is more difficult to read the text.

Expected result:
The lines of the table/date format text of the form should be properly displayed on high contrast high mode
 The text should be readable on High Contrast Black mode
Bug: There are no borders on the form when rendering a pdf file on high contrast black
Status: VERIFIED
Priority: P3
Resolution: DUPLICATE
Created: 2021-06-14 15:31:18+00:00
Resolved: 2021-08-03 11:09:43+00:00

Tested with:
Nightly 91.0a1 (2021-06-13)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:
1. Turn on the Hight Contrast Black on your system
2. Launch Firefox
3. Open the following pdf: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033

Actual result:
There are no borders on the form when printing a pdf file on high contrast black

Expected result:
The form should be displayed with borders on high contrast black.
Bug: Data loss when updating to Firefox 68
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-14 17:40:07+00:00
Resolved: 2021-06-15 07:12:43+00:00

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

Steps to reproduce:

completed suggested update from 60.9.1 (32-bit) o 68.12.1 and lost everything!


Actual results:

completed suggested update from 60.9.1 (32-bit) o 68.12.1 and lost everything!
Bug: Text from the first page of the pdf is not displayed
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-06-14 18:05:15+00:00
Resolved: 2021-07-08 11:19:43+00:00

Tested with:
Nightly 91.0a1 (2021-06-14)

Tested on:
Win 10

Preconditions:
In about:config, set pdfjs.enableXfa = true

Steps:

1. Launch Firefox
2.. Open the attached pdf.

Actual result:
Text from the first page of the pdf is missing and an error is displayed in console. Page number is incorrectly displayed. Text from section 3 overlaps. See screenshots. 

Expected result:
The first page of the doc is properly displayed and there is no errors in console. Page number and text from section 3  are properly displayed.