av9ash/GitBugs huggingface dataset:
Bug: Protection level in Protection UI remains in English
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-30 05:08:32+00:00
Resolved: 2020-04-30 10:43:00+00:00

We recently migrated the panel to Fluent in bug 1609559, but I think the issue is caused by bug 1587870, which originally introduced the label.
https://hg.mozilla.org/mozilla-central/rev/26fe0b14808f

Looks like we're setting an attribute `label`, when we should set the value?

```
<label xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" id="protections-popup-footer-protection-type-label" data-l10n-id="protections-popup-footer-protection-label-custom" label="Personalizzata">Custom</label>
```
Bug: Right click on tab or page triggers only once
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-30 07:31:10+00:00
Resolved: 2020-05-05 09:14:32+00:00

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

Steps to reproduce:

Open Firefox Developer Edition 76.b8 from the dock on Mac OS Catalina 10.15.4
Mouse right click  on a tab or inside a page. 

I use Apple mouse 2 via Bluetooth.


Actual results:

First mouse right click on a tab or page. Context menu opens.
Mouse right click on tab again. Nothing happens.
Mouse right click on the page. Nothing happens.


Expected results:

Every mouse right click should displays context menu depending on where I clicked.

Short summary. Mouse right click shows context menu only for the first click. Next mouse right clicks don't work.
Bug: Group Policies stops working if bookmarks have non-ascii characters (like Ñ) in the registry
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-30 08:20:38+00:00
Resolved: 2020-05-24 00:42:06+00:00

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

Steps to reproduce:

Add Windows (GPO) in Active Directory.
Software\Policies\Mozilla\Firefox\Bookmarks\1\Title = "Logroño"
Software\Policies\Mozilla\Firefox\Bookmarks\1\URL = "https://logroño.es"



Actual results:

Firefox group policies are no longer applied, stop working and not change browser settings.


Expected results:

Add custom certificates and custom bookmarks, and more settings.
Bug: [Hero Layout] Padding for small cards is not changed for browser larger breakpoints
Status: RESOLVED
Priority: P2
Resolution: WONTFIX
Created: 2020-04-30 08:29:05+00:00
Resolved: 2024-01-18 22:04:18+00:00

**[Affected versions]:**
- Firefox Nightly 77.0a1 Build ID 20200429215539;

**[Affected Platforms]:**
- Windows 10;
- Mac OS 10.15.3;
- Ubuntu 18.04 x64;

**[Prerequisites]:**
- Set browser.newtabpage.activity-stream.discoverystream.endpoints to http,https
- Set browser.newtabpage.activity-stream.discoverystream.config to {"api_key_pref":"extensions.pocket.oAuthConsumerKey","collapsible":true,"enabled":true,"show_spocs":true,"hardcoded_layout":false,"personalized":true,"layout_endpoint":"https://e5e8374d-fffa-4a77-a604-31603852b6fd.mock.pstmn.io/layout/1628045"}

Note: If no spocs show up, you may need to set browser.newtabpage.activity-stream.discoverystream.spocs-endpoint to https://e5e8374d-fffa-4a77-a604-31603852b6fd.mock.pstmn.io/spocs/v2 

- Have the browser at >939px width;

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Open about:newtab page.
3. Tap “F12” key to open the browser Inspector.
4. Observe small cards padding (from the “Hero” section).

**[Expected result]:**
- Small cards padding is 16px.

**[Actual result]:**
- Small cards padding is 8px, the same as for browser smaller breakpoints.
Bug: Preferences modal not closed when navigating between subpages
Status: NEW
Priority: P3
Created: 2020-04-30 09:14:00+00:00
Resolved: 2020-05-12 00:58:19+00:00

**Affected versions**
* 76.0, 77.0a1; 75.0;

**Affected platforms**
* macOS 10.15.3, Ubuntu 18, Windows 10;

**Steps to reproduce**
1. Launch Firefox, access about:preferences
2. Navigate between the subsection (general/home/search/security/updates);
3. Click on the General subsection (about:preferences#general)
4. Scroll to Fonts and click to open the Advanced modal;
5. Click on the Back button to navigate to previous page

**Expected result**
* modal should close even if navigating to another subpage;

**Actual result**
* navigation is unhindered  but modal remains displayed;

**Regression range**
* bit tricky since considering old behaviours had to take as good builds that when pressing back did close the menu but did not navigate to the previous subpage;
* First bad: 2017-06-05;
* Last good: 2017-06-04;
* Pushlog: [URL](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=130efc657df7e7fe291cc42307f3eb3cb0484dfc&tochange=275588f4d852d7dc183a9dcc70a311413dc7a063)
* Potential regressor:


**Additional notes**
* attached recording with the issue.
Bug: More Information section on Tracking Protection panel is not consistently expandable
Status: RESOLVED
Priority: P2
Resolution: WORKSFORME
Created: 2020-04-30 10:04:45+00:00
Resolved: 2024-08-14 18:30:26+00:00

**Affected versions**
- 77.01 (2020-04-29)

**Affected platforms**
- Ubuntu 18.04

**Steps to reproduce**
1. Open any website (eg. https://www.reddit.com/)
2. Click on the Shield icon inside the address bar
3. Click on the “i” button 

**Expected result**
- The More info panel is expanded, the content is visible

**Actual result**
- The More info panel is expanded but empty; at the third attempt the panel is no longer expandable  

**Regression range**
- I double checked a regression range and ended up with the following: 

    - Last good revision: db2e1d780268ab0a7dca1ea1ca81febcb33e926e (2020-04-24)
    - First bad revision: 6ba63b50d93083c798f4eccdbeded15441bd1979 (2020-04-25)
    - Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=db2e1d780268ab0a7dca1ea1ca81febcb33e926e&tochange=6ba63b50d93083c798f4eccdbeded15441bd1979


**Additional notes**
- I don’t have a 100% reproducibility rate with a clean profile, but nevertheless the rate is very high (around 8/10)
- I only manage to reproduce it on Ubuntu
- The issue is reproducible even if  waiting for the website to be loaded completely before opening the protection panel
- "TypeError: can't access property "disabled", learnMoreLink is null" is the error triggered inside console
Bug: White flash on Find in Options search field when restarting Firefox on about:preferences page or when opened from hamburger menu for the first time
Status: NEW
Priority: P3
Created: 2020-04-30 10:55:54+00:00
Resolved: 2021-03-23 21:49:49+00:00

*Affected versions*
* 77.0a1 (20200430082621)
* 76.0 (20200429185419)

*Affected platforms*
* Windows 10x64


*Steps to reproduce*
1. Open Firefox and go to about:preferences..
2. Restart Firefox while about:preferences is opened (Ctrl+ Shift+ J -> Ctrl +Alt+  R).

*Expected result*
* No visual glitches on about:preferences page.

*Actual result*
* White flash on `Find in Options` search field.


*Regression Range*
Last good revision: 7f9f804e9dbe81bce013bf4dea28074744b568f6 (2020-03-30)
First bad revision: 9af589864188fc4061a020c45914f54fa9f67b0d (2020-03-31)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7f9f804e9dbe81bce013bf4dea28074744b568f6&tochange=9af589864188fc4061a020c45914f54fa9f67b0d
Possible regressor: Bug 1625314


*Notes*
* Attached a screen recording.
* The issue can be reproduced as well by opening Firefox with a new profile and going to about:preferences from the hamburger menu.
* The issue can be reproduced with Windows Light theme too but is more visible with  Dark theme enabled (Setting -> Personalization-> Colors -> Dark).
Bug: [Edit this Bookmark panel] "Bookmarks folder" tree breaks if the tree view is hidden and displayed again after creating a new folder
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-30 12:30:58+00:00
Resolved: 2020-06-11 19:57:36+00:00

**Affected versions**
* Firefox 68.8.0esr
* Firefox 76.0 
* Firefox 77.0a1 (BuildId:20200430082621)

**Affected platforms**
* macOS 10.14

**Unaffected platforms**
* Windows 10 64bit
* Ubuntu 18.04 64bit

**Steps to reproduce**
1. Launch Firefox.
2. Bookmark a random webpage.
3. Click the “star shaped” button in order to open the “Edit This Bookmark” panel.
4. Click the “Show all the bookmarks folders” button.
5. Click the “ + New Folder” button in order to add a new folder inside the tree view (Don’t edit/save the newly created folder).
6. Click the “Hide” button.
7. Click the “Show all the bookmarks folders” button again.

**Expected result**
* The bookmarks folders tree view is successfully displayed.

**Actual result**
* The bookmarks folders tree view is displayed as broken and the only visible element is the newly created folder.
* The following error message is being outputed by the Browser Console while triggering this issue: `TypeError: can't access property "title", node is undefined   treeView.js:1814:9`

**Regression Window**
This seems to be a regression.
* Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e41d07a703f19224f60b01577b2cbb5708046c9&tochange=09a4282d1172ac255038e7ccacfd772140b219e2
* I tried to track down the exact regressor and I think that "Bug 1376925 - Modernise browser_bookmarksProperties.js to use async functions and assert." has introduced this behavior.

**Notes**
* For further details regarding this issue please observe the attached screencast.
* It seems that only a browser restart can fix this issue (Bookmarking a new page & Removing the bookmark doesn’t seem to fix this). Also, while this issue is triggered the newly created folder can’t be created inside the tree view and the “+ New Folder” doesn’t seem to respond to click events.
Bug: Pattern in background of page disappears on its own
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-30 12:53:29+00:00
Resolved: 2020-06-02 11:03:52+00:00

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

Steps to reproduce:

Wrote simple test page (https://depesz.com/test/test.html), and visited it from Firefox 75 on Linux (debian, and two different releases of ubuntu, using Firefox from debs or downloaded as .tar.gz from mozilla).

Then, I opened new tabs, and browsed the web in them for some time (usually a minute is enough, sometimes longer).

The longer I browse web in other tabs, and the more tabs i use, the more likely it is that the bug will manifest.


Actual results:

Upon going back to test page, I noticed that background is missing.


Expected results:

The background should still be there.

I tried making the background image larger (20x20px), or using "position:fixed" hack/fix that I found on some page - nothing helped.
Bug: Deleting the imported username and typing few chars back in the field will re-trigger the Password Import Autocomplete wizard
Status: NEW
Priority: P3
Created: 2020-04-30 12:58:56+00:00
Resolved: 2020-07-07 22:49:37+00:00

**[Affected versions]:**
- Firefox Nightly 77.0a1 Build ID 20200429215539;

**[Affected Platforms]:**
- Windows 10;
- Mac OS 10.15;

**[Prerequisites]:**
- Have at least a pair of credentials saved in latest Chrome (i.e for Facebook);
- In Firefox set “signon.showAutoCompleteImport” pref to “import”;

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Open in Firefox the site for which you saved credentials.
3. Click on the username field.
4. Start and finalize the password autocomplete import wizard, by clicking on the dropdown option.
5. Click the username field and select the saved suggestion.
6. Delete the username and type back a few random chars.

**[Expected result]:**
- Nothing is displayed or maybe only the saved suggestions.

**[Actual result]:**
- The Password Import Autocomplete suggestions are displayed and if clicked the import wizard is re-triggered.

**[Notes}:**
- This is not happening from the password field.
Bug: The Password Import Autocomplete suggestion is displayed on Linux
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-30 13:03:45+00:00
Resolved: 2020-08-25 11:56:37+00:00

**[Affected versions]:**
- Firefox Nightly 77.0a1 Build ID 20200429215539;

**[Affected Platforms]:**
- Linux Ubuntu 18.04;

**[Prerequisites]:**
- Have at least a pair of credentials saved in latest Chrome (i.e for Facebook)
- In Firefox set “signon.showAutoCompleteImport” pref to “import”

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Open in Firefox the site foe which you saved the credentials.
3. Click on the username field.
4. The password autocomplete import suggestion is displayed.

**[Expected result]:**
- Nothing should be displayed, because importing passwords is not possible while using Linux.

**[Actual result]:**
- The Password Import Autocomplete option is displayed, and the import wizard can be triggered.

**[Notes}:**
- Finalizing the wizard will have no effect, and the import suggestion will be re-displayed.
- The wizard options are correct - don’t contain password options to be imported.
Bug: Date information are shown in about:logins page for RTL builds only after the page is refreshed
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2020-04-30 13:35:52+00:00
Resolved: 2022-06-21 13:37:32+00:00

**Affected versions**
- 77.0a1
- 76.0


**Affected platforms**
- Windows 10
- macOS 10.15
- Ubuntu 18.04

**Steps to reproduce**
1. Open a RTL Firefox build (eg. ar)
2. Save credentials for any website (eg. https://www.facebook.com/)
3. Open the about:logins page
4. Observe the تاريخ الإنشاء (Created) / آخر تعديل (Last modified) / آخر استخدام (Last used) fields

**Expected result**
- The date of the corresponding action is displayed for every section

**Actual result**
- “???” is shown instead of dates

**Regression range**
- I ran a regression manually with the following result:
  - https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3e5a7430c8d7d87bfeff471e62643185393a34c6&tochange=c644dd16e2ccf8bb78268202f60c767a569d9d77

**Additional notes**
- The dates are shown after the about:loggins page is refreshed once
- Reproducible on he locale (RTL build as well)
- Not reproducible on en-US, de, zh-CN
Bug: [mac] Applications icons are not properly centered in about:preferences
Status: NEW
Priority: P3
Created: 2020-04-30 13:38:32+00:00
Resolved: 2022-10-10 19:29:38+00:00

**Affected versions**
* 45.0, 75.0, 76.0, 77.0a1 (2020-04-29);

**Affected platforms**
* macOS 10.15.3

**Steps to reproduce**
1. Launch Firefox and access about:preferences#general
2. Scroll down to the Applications section;
3. Click on any dropdown from Action section (Always ask);

**Expected result**
* icon aligned with text;

**Actual result**
* icon shifted up a few pixels;

**Regression range**
* not a regression;

**Additional notes**
* attached screenshot with the issue;
* Windows 10 / `ubuntu 18.04 not affected.
Bug: Search Configuration - Distribution order hints  are not defined for okru-001 -uz/uz
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-30 14:31:56+00:00
Resolved: 2020-04-30 15:50:48+00:00

##### [Environments:]
Windows10

###### baseline:
      partner build - http://ftp.mozilla.org/pub/firefox/candidates/75.0b9- 
      candidates/build1/partner-repacks/mailru/okru/v1/win64/uz/
      region: UZ

###### modern-configuration
     Nightly -uz build 20200430
     region: UZ
     simulated distribution ini code:  okru-001 

The order for the engines in the modern configuration is wrong; from the Search-helper extension, seems that the orderhint is undefined in the main-preview.
Bug: Color of container indicator in tab bar does not update when changing it
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-04-30 15:11:34+00:00
Resolved: 2020-05-04 20:56:33+00:00

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

Steps to reproduce:

Using multi-account containers, open a tab in any container, then go to your settings and change the color for that container


Actual results:

The colored bar in the tab indicating what container is used did not update until reopening the tab

(it is unknown if this behaviour is avoided by closing any tab or closing all tabs of a container)


Expected results:

The colored bar in the tab indicating what container is used should change color to reflect the new setting
Bug: Intermittent browser/base/content/test/sidebar/browser_sidebar_adopt.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-04-30 15:36:55+00:00
Resolved: 2020-05-26 17:03:53+00:00

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

---

[task 2020-04-30T14:15:23.534Z] 14:15:23     INFO - TEST-START | browser/base/content/test/sidebar/browser_sidebar_adopt.js
[task 2020-04-30T14:17:18.024Z] 14:17:18     INFO - TEST-PASS | browser/base/content/test/sidebar/browser_sidebar_adopt.js | SidebarShown event fired on an adopted window - 
[task 2020-04-30T14:17:18.027Z] 14:17:18     INFO - Leaving test bound testEventReceivedInNewWindow
[task 2020-04-30T14:17:18.029Z] 14:17:18     INFO - Buffered messages finished
[task 2020-04-30T14:17:18.032Z] 14:17:18     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/sidebar/browser_sidebar_adopt.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2020-04-30T14:17:18.081Z] 14:17:18     INFO - GECKO(1089) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2020-04-30T14:17:18.100Z] 14:17:18     INFO - GECKO(1089) | MEMORY STAT | vsize 3020MB | residentFast 352MB | heapAllocated 120MB
[task 2020-04-30T14:17:18.127Z] 14:17:18     INFO - TEST-OK | browser/base/content/test/sidebar/browser_sidebar_adopt.js | took 110819ms
[task 2020-04-30T14:17:18.129Z] 14:17:18     INFO - GECKO(1089) | ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /tmp/tmpvLKDdY.mozrunner/runtests_leaks_tab_pid1579.log
[task 2020-04-30T14:17:18.135Z] 14:17:18     INFO - GECKO(1089) | [1579, Main Thread] WARNING: XPCOM_MEM_BLOAT_LOG is set, disabling native allocations.: file /builds/worker/checkouts/gecko/tools/profiler/core/platform.cpp, line 224
[task 2020-04-30T14:17:19.208Z] 14:17:19     INFO - checking window state
[task 2020-04-30T14:17:19.781Z] 14:17:19     INFO - GECKO(1089) | [Child 1550: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 0x7f0445cd9c00 == 0 [pid = 1550] [id = {db74e071-4f34-417a-8958-d2b744f832d8}] [url = about:blank]
Bug: White text on white background in the Find text box
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-04-30 16:03:07+00:00
Resolved: 2024-02-22 07:42:59+00:00

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

Steps to reproduce:

I run firefox in Ubuntu with the following theme settings:

- System GTK is set to Adwaita-dark
- Firefox theme is set to Light


Actual results:

I bring up the search box in any page with Ctrl-F and type. White text on white background is the result


Expected results:

I should be getting white text on white background. It works properly if I do any of the following:

- Set the system theme to the normal light Adwaita
- Set the firefox theme to the default or dark themes
- Set the system to light Adwaita and Firefox to the dark theme (the exact opposite)

For some reason only this combination causes a problem.
Bug: ph signup component is not filtered out if pocket content is turned off
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-04-30 17:40:50+00:00
Resolved: 2020-05-04 14:47:38+00:00

If you turn pocket off the signup component still shows in the middle of the page.

It needs to be added to the filter list.

This happened to collection to.

I think we need a better solution than a list of pocket components, but probably not something we want to fix here.
Bug: / before a . within a URL sometimes causes infinite reloading
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-30 19:17:53+00:00
Resolved: 2020-05-08 08:17:51+00:00

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

Steps to reproduce:

Type in any of the following URLs:
- `application/.com`
- `application\.com`
- `applicatio/.com`
- `applicati/.com`
- `applicat/.com`
...
- `appl/.com`

This is where it gets interesting: `app/.com` doesn't infinitely redirect. Other names that don't infinitely redirect:
- foo
- chrome
- google
Names that do infinitely redirect:
- chrom
- bar
- com
- org
- twitter
- about

The extension does not seems to matter as long as it's there (eg it can be a single quote)


Actual results:

Indefinite reloading of the page


Expected results:

Server Not Found error
Bug: Search Configuration - Default search engine difference in okru-001 - KK/KZ
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-30 20:54:30+00:00
Resolved: 2020-06-26 16:30:26+00:00

Tested on Windows10

baseline:
partner build - http://releases.mozilla.org/pub/firefox/candidates/75.0b9-candidates/build1/partner-repacks/mailru/okru/v1/win64/kk/Firefox%20Setup%2075.0b9.exe
Region: KZ


modern-configuration
Nightly -KK build  20200430082621
region: KZ
 simulated distribution ini code:  okru-001 


I get yandex on nighly build  and mail.ru on the partner  one
Localization kk region  KZ was used since i belive that is for Kazakhstan
Bug: Investigate improving sync IO caused by app updater in the interventions provider
Status: NEW
Priority: P3
Created: 2020-04-30 23:59:18+00:00
Resolved: 2020-05-12 00:58:58+00:00

See bug 1632918. We fixed that bug by moving the first app update check from the first time the urlbar is used to the first time the update intervention is triggered. There's still jank then that we should fix somehow. My comment 5 there discusses some options. In summary, we could make all the IO in the app updater async, or we could just not trigger update checks from the interventions provider at all. That's only two options, there may be others I didn't think of.
Bug: Open starts on blank page instead of custom url v75.0
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-05-01 07:32:50+00:00
Resolved: 2020-05-25 09:28:52+00:00

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

Steps to reproduce:

Options > New windows & Tabs > New windows & Homepage Custom URL as https://www.office.com/?auth=2&home=1
New Tabs as default.

(Desktop user)


Actual results:

Completely Blank page. No error, no info, just a search bar.


Expected results:

Opened the URL https://www.office.com/?auth=2&home=1