av9ash/GitBugs huggingface dataset:
Bug: [mac+ubuntu] Preferences - color picker for Fonts and color remains in view and can be bypassed
Status: NEW
Priority: P3
Created: 2020-04-14 11:57:58+00:00
Resolved: 2020-05-27 14:53:59+00:00

**Affected versions**
* 75.0, 76.0b4, 77.0a1(2020-03-13);

**Affected platforms**
* macOS 10.15.3, Ubuntu 18.04;

**Steps to reproduce**
1. Launch Firefox, access about:preferences#general
2. Scroll down to Language and Appearance;
3. Click on the Color button;
4. Click on any color change button;
5. Click behind the color picker frame to close that modal(not the color picker);

**Expected result**
* nothing happens;

**Actual result**
* color picker window is ignored and remains in view;

**Regression range**
* First bad:  (2018-10-05)
* Last good: (2018-10-04)
* Pushlog: [URL](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=301f1711aab2fabca34a6c80d6bf4f42779b0c01&tochange=54cb6a2f028b033ef567f00af2f82f5fb97ab437);

**Additional notes**
* attached recording with the issue;
* issue does not reproduce on Windows 10.
Bug: [mac+win] Preferences - font picker dropdown shows horizontal scroll bar if searching therms
Status: NEW
Priority: P3
Created: 2020-04-14 13:25:56+00:00
Resolved: 2020-06-17 15:34:03+00:00

**Affected versions**
* 76.0b4, 77.0a1 (2020-04-14);

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

**Steps to reproduce**
1. Launch Firefox, resize the browser @ half the screen;
2. Scroll down to Language and Appearance;
3. In the top-right corner search for "ar";
4. Click on the Default Font button;
5. Open the menu and scroll up/down;

**Expected result**
* menu is displayed with all options listed as expected;
* could use a confirmation still on desired UI/UX layout;

**Actual result**
* horizontal scroll bar displayed, menu limited but extra spacing appears to be added as well;

**Regression range**
* First bad: 2020-03-30;
* Last good: 2020-03-29;
* Pushlog: [URL](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d5efb485c09c230a90fc2a24ba473ae35c1963f2&tochange=7f9f804e9dbe81bce013bf4dea28074744b568f6); 

**Additional notes**
* attached recording - comparison between 76.0b4 and 45.0esr.
Bug: [Windows] No "username or password is incorrect" or "account lockout" message is displayed when entering invalid password in the OS auth dialog
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-04-14 13:27:21+00:00
Resolved: 2020-04-22 15:53:21+00:00

[Affected versions]:
- Nightly 77.0a1;
- Beta 76.0b4;

[Affected Platforms]:
- Windows 10 x64;
- Windows 7 x64;
- Windows 8.1 x32;

[Prerequisites]:
- Have an OS password set.

[Steps to reproduce]:
1. Open the latest Nightly Firefox browser.
2. Navigate to the "about:logins" page and select a saved login.
3. Click on the "Show Password" button.
4. Enter an invalid password in "Windows Security" dialog.

[Expected result]:
- The "username or password is incorrect" message is displayed under the password filed.

[Actual result]:
- No "username or password is incorrect" message is displayed.

[Notes]:
- The issue is also reproducible if the OS have set a lockout policy that blocks the account after failing to login after a defined number in the policy. For example if the "Account lockout threshold" is set to 3 invalid login attempts, the account will be locked if an invalid password is entered 3 times. In this case the user will not see any message displayed that informs him about the "account lockout" and this can be confusing for the users.
- However, I looked how Chrome behaves in this situation and it seems that an message is displayed in both cases. If an invalid password the "The username or password is incorrect" and if the account is locked the "The referenced account is currently locked out and may not be logged on to" message is displayed.
- Attached a screen recording with the issue.
Bug: Downloads list items appear out of view in panel and is unreadable macOS
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-14 14:38:19+00:00
Resolved: 2020-04-16 12:06:02+00:00

OS: macOS 10.15.4
Firefox Nightly: 77.0a1 (2020-04-14)

When navigating to the Downloads panel from the Library menu, the list appears to flow out of view. See attached screenshots. There also appear to be some artifacts in the rendering of the panel, see the footer section.
Bug: Switch-to-tab icon in the address bar is white
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-14 14:54:42+00:00
Resolved: 2020-09-01 09:10:00+00:00

Screenshot attached. This icon should be displayed with the colours defined [here](https://searchfox.org/mozilla-central/rev/2cd2d511c0d94a34fb7fa3b746f54170ee759e35/browser/themes/shared/urlbar-autocomplete.inc.css#237-238,247-248).
Bug: The about:protection is not properly displayed when refreshing the page
Status: NEW
Priority: P5
Created: 2020-04-14 15:06:22+00:00
Resolved: 2020-05-20 08:58:05+00:00

**Affected versions**
* 75.0
* 76.0b4
* 77.0a1 (2020-04-14)

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


**Steps to reproduce**
1. Launch Firefox.
2. Go to about:protections
3. Go down the page.
4. Press F5 many times in order to refresh the page.
4.1. Click on the Refresh button many times.

**Expected result**
* 4. The page is correctly refreshed.
  4.1. The page is correctly refreshed. 


**Actual result**
* 4. The page jumps at the bottom.
  4.1. The page jumps at the top. 

**Regression range**
* Last good revision: d1e7315a88f324c3ed5a58f08d8c42ce99ae473f
First bad revision: b1274d0f0ce1f3596fb9bc6d07f5f1aca5821a84
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d1e7315a88f324c3ed5a58f08d8c42ce99ae473f&tochange=b1274d0f0ce1f3596fb9bc6d07f5f1aca5821a84

Potentially regressed by:1559421

**Additional notes**
* see the attached screenrecording
Bug: New address bar too narrow on narrow screens
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-14 15:16:21+00:00
Resolved: 2020-04-29 09:59:55+00:00

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

Steps to reproduce:

Updated to Firefox with the new address bar, on my (Fedora Linux) system where Firefox is in a 1080x1920 window (maximized on a portrait-orientation FHD screen).


Actual results:

The autocomplete / suggestion / whatever list that appears when you start typing in the new address bar seems now to only ever render as wide as the address bar itself. Which on a 1080 wide window, with a search box and a few plugins, is only about 573 pixels wide. The margins and the 'fade out' effect on the right hand side of the list effectively eat a little more of that, to the point where you almost never get anywhere close to the full URL *or* full title of any page in the list. This is particular a problem for trying to sort through many similar URLs, for instance...Bugzilla bugs. See attached screenshot.


Expected results:

It should be possible for this UI element to be much wider, as it was in the previous design. I understand that this doesn't matter a lot if the window is very wide, as is often the case on landscape-oriented screens, but it's a big problem if it isn't.
Bug: Personality Provider isn't properly rehydrating itself with cached values
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-14 15:17:26+00:00
Resolved: 2020-04-24 14:12:33+00:00

If we re initialize a personality provider using cache, it's not properly passing the previous cached score into the new insistence, causing it to make them fresh which is not really ideal.
Bug: Search bar calls into SearchService.defaultEngine twice for each call to updateDisplay
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-04-14 15:47:34+00:00
Resolved: 2020-04-16 09:51:04+00:00

Currently the search bar's `updateDisplay()` function is doing two private browsing checks and calling into SearchService.`defaultEngine` (or `defaultPrivateEngine`) twice each time it is called:

https://searchfox.org/mozilla-central/rev/2cd2d511c0d94a34fb7fa3b746f54170ee759e35/browser/components/search/content/searchbar.js#230,234

Although we cache the search engine defaults, this seems highly unnecessary and is causing us to go across the component boundaries twice when we don't need to.

We should therefore simplify that function to use an intermediate variable.

This won't have a significant effect on performance but it would help with debugging and reduce unnecessary calls to the search service.
Bug: Doorhanger anchor highlight shows a bigger area than clickable
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-04-14 15:59:29+00:00
Resolved: 2020-04-27 11:01:22+00:00

##### [Environment:]
 	
        77.0a1 20200414094457
        76.0b4 20200412214314

using:

         Ubuntu 18.04, Windows 10, Mac 10.13.6
        

##### [Steps:]
1. Start-up Firefox. 
2. Access any login form.
3. Input any text as a password in the login form, then focus away.
4. Highlight the grey key in the permissions pannel.
5. Highlight the grey key, then click exactly on the key, then focus away. 
6. Highlight again the grey key, then click towards any of the corners of the highlight.

##### [Actual Result:]
5. There is a click animation and password Message pannel is opened.
6. There is a click animation but password Message pannel is not opened.

##### [Expected Result:]
In both cases, the password permissions pannel is opened.

##### [Note:]
1. Althought the fix in bug 1570391 makes this issue a lot more visible and gives the impression the permission dismissed doorhanger icon doesn't always work, it is my impression that this is an older deeper issue here.
2. Towards the end of the screencast, when the focus moves from the grey icon toward the security icone, the highlight remains on the dismissed password icon, the highlight encapsulating now both of the icons - a separate bug can be logged for this issue if need be, but it seems to me that is somehow the same issue as bug 1570391.

##### [Regression Range:]
2020-04-14T18:21:30: DEBUG : Found commit message:
Bug 1570391 - Trigger highlighting when hovering over notification icon. r=johannh,pbz

Differential Revision: https://phabricator.services.mozilla.com/D67737
Bug: Personality Provider worker should terminate
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-14 16:02:10+00:00
Resolved: 2020-05-07 13:45:39+00:00

We don't need to terminate the worker generally.

But if there is a case where a pref changes, we might still instantiate a new one, and teardown any existing ones. In this case, we should probably terminate the worker freeing up the memory in the worker thread.
Bug: Address bar stuck in expanded focus state in restored tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-14 16:31:08+00:00
Resolved: 2020-04-15 10:44:49+00:00

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

Steps to reproduce:

Restore previous session


Actual results:

Tab is restored and address bar is in expanded focus state but not actually focused, so clicking elsewhere does nothing because it's not losing focus.


Expected results:

Address bar should appear normal, not expanded and no focus ring.
Bug: The two "new tab" buttons have different accessible label
Status: NEW
Priority: P3
Created: 2020-04-14 16:31:22+00:00
Resolved: 2023-12-09 00:03:07+00:00

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

Steps to reproduce:

Get the accessible name of the 2 "New tab" buttons (the one when there are "few" tabs, and the one when there are "many" tabs)


Actual results:

They have a different label.  The "few" tabs one states "Open a new tab (Ctrl+T)", and the "many" tabs one states "New tab".


Expected results:

Both buttons which provide the exact same feature and apparently are only different buttons for internal reasons should have the same label to improve consistency and avoid confusion.  This affects users of assistive technologies like screen readers.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1628360#c14
Bug: no title in Window menu for text file, when tab shows filename, an obvious title
Status: NEW
Priority: P3
Created: 2020-04-14 20:28:41+00:00
Resolved: 2020-05-15 15:49:33+00:00

If I am viewing a text file (with extension ".txt") in FF, I see the window title as "Mozilla Firefox". See screenshot.

Is there a reasonable title to put there? The tab title is "gao.gov/assets/710/705803.txt", which is part of the URL. This seems very reasonable.

So why not use the exact same title on the window title bar and in the list of items in the "Window" menu?
Bug: A race condition on startup can lead to the wrong engine being set as default
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-04-14 20:43:13+00:00
Resolved: 2020-06-25 16:12:08+00:00

Whilst working on another bug, I found a case where a race condition would lead to the wrong engine being set as default on startup.

Practically speaking, I think this is rare and unlikely, though I have seen reports in the wild of related things happening. The STR I have are ones that wouldn't happen for a normal user.

Manufactured STR:

1. In code in `fetchRegion`, arrange for the region to be overridden to set it to `RU`. The network call should still happen at this point.
2. Set up a fresh Firefox profile, add the search bar to the toolbar.
3. Shutdown Firefox.
4. Remove the `browser.search.region` preference from the profile's `prefs.js`
5. Remove `search.json.mozlz4` from the profile.
6. Start Firefox.

I can reproduce this on builds back to release, I haven't gone further as I suspect it isn't really a regression. On Mac I can reproduce that Amazon.com gets set as default 100% of the time with the above STR. If I avoid the network fetch, so that the region is set before list.json (or the modern config) is read, then it correctly sets the default engine.

This is unlikely to be reproduced by a user as we don't normally reset the `browser.search.region` preference, and new profiles don't have the toolbar on automatically.
Bug: misuse _NET_WM_DESKTOP  for session restore to virtual desktop
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-14 22:37:26+00:00
Resolved: 2020-04-16 02:15:16+00:00

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

Steps to reproduce:

Call nsWindow::MoveToWorkspace() with an invalid workspaceIDStr. Say I currently have 1 virtual desktop and call it with "2".

Also expecting the same order after a restart of the WM. For example to restore the windows after a reboot.


Actual results:

nsWindow::MoveToWorkspace() without checking if the virtual desktop is valid requests to switch to the 3rd virtual desktop which is invalid by setting _NET_WM_DESKTOP to 2. This is not really defined by the freedesktop spec specifications.freedesktop.org.

There is also no real definition of order by the freedesktop spec which can be confusing especially for dynamically created desktops.


Expected results:

nsWindow::MoveToWorkspace() should check if the workspaceIDStr is valid before requesting.

Check if the order and count of the virtual desktops is the same after restarts.
Bug: TRR canary check returns "disable_doh" if the DNS request fails
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-04-14 23:16:26+00:00
Resolved: 2020-07-24 10:49:22+00:00

The application DNS canary check in the DoH rollout addon returns `disable_doh` if the DNS request fails (for example, because the network is disconnected). These are probably inflating our disable rates.

I think the check should only return `disable_doh` if the check affirmatively fails according to the criteria in https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet.

STR:
1. Visit about:devtools-toolbox?type=extension&id=doh-rollout@mozilla.org and run `await globalCanary()` in the console; result should be `enable_doh`.
2. Disconnect the network.
3. Repeat. Expected result to be `enable_doh`; result was `disable_doh`.
Bug: Loading spinner animates forever if tabs is discarded while loading
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-15 06:04:45+00:00
Resolved: 2021-03-11 18:20:28+00:00

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

Steps to reproduce:

1. Install tabs-tabs-tabs[1], Tab Center Reborn[2] or any other extension that has the tabs permission
[1]: https://github.com/mdn/webextensions-examples/tree/master/tabs-tabs-tabs
[2]: https://addons.mozilla.org/firefox/addon/tabcenter-reborn/
2. Type `await browser.tabs.query({});` and get the id of a tab you can discard
3. Type `await browser.tabs.reload(tabId); setTimeout(() => browser.tabs.discard(tabId), 30);` by using the the tab id of above.

Note that this is not a theoretical case I can trigger it by doing F5 and unloading the tab with an extension that adds a context menu entry to do that.


Actual results:

Tab is discarded but the loading spinner doesn’t go away.

`await browser.tabs.get(tabId);` reports the tab as both `discarded: true` and `status: loading`.


Expected results:

– Discarded tab get back its favicon, instead of the loading spinner.
– WebExtensions API reports its status as `complete` instead of `loading` like for other discarded tabs.
Bug: Firefox Send not working properly since 3 weeks
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-15 08:10:45+00:00
Resolved: 2020-04-15 09:39:29+00:00

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

Steps to reproduce:

Under Firefox 75.0 i try since 3 weeks to use Firefox Send.


Actual results:

It doesn't work : "an error occured" 


Expected results:

take my archives and make a cloud link to transfer ...
Bug: Search bar oversized on my browser whenever I use it, please help
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-04-15 08:47:53+00:00
Resolved: 2020-04-15 17:30:56+00:00

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

Steps to reproduce:

Click on my search bar after the update. Then spend an hour trying to find out how to fix it. Then came here.


Actual results:

The searchbar gets really big and is in the way of things on my screen. Makes me stressed. I do not like it. I've checked the web, and it seems my best choice is to go back to Chrome? There has got to be a better solution.


Expected results:

I should have been able to type in it normally, it shouldn't have become oversized when I used it. Please help. It is so unpleasant to use, that I have already reinstalled Chrome in an attempt to find an alternative.
Bug: batch removal from history is extremely slow
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-15 09:55:14+00:00
Resolved: 2020-04-22 07:42:02+00:00

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

Steps to reproduce:

 - Open the history window (History > Show All history)
 - In the search field, type the name of a site you visit often (with a few thousand entries)
 - Select all the results
 - Right click
 - Select “Delete Pages”


Actual results:

the whole browser UI immediately becomes unresponsive (not only the history window)
after some time, the "unresponsive script" popup appears, pointing to "chrome://browser/content/places/controller.js:327"



Expected results:

The selected entries should be deleted
Bug: 3+ minute long session restores on AMD E2-7110, Linux
Status: NEW
Priority: --
Created: 2020-04-15 11:59:05+00:00
Resolved: 2025-03-02 14:52:29+00:00

Initially reported at: https://www.reddit.com/r/firefox/comments/g0myck/4_minutes_startup_time/

### Basic information

Steps to Reproduce: 

Restore from session

Expected Results:

Fast restore.

Actual Results:

3+ minute long session restores.

---


### More information

Profile URL: https://perfht.ml/2ydmFUs

#### Basic systems configuration:

OS version: linux mint 19.3

GPU model: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R3 Graphics]

Number of cores: 4 (AMD E2-7110) 

Amount of memory (RAM): 8GB

Thanks so much for your help.
Bug: About:newtab does not maintain the scroll position after navigating back to the page
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2020-04-15 12:44:35+00:00
Resolved: 2020-04-30 12:31:55+00:00

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

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

**[Prerequisites]:**
- Have an en-US locale build;
- Have the “browser.search.region” pref set to “US”;
- Have the “browser.tabs.remote.separatePrivilegedContentProcess” pref set to “true”;

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Open about:newtab page.
3. Scroll down the page and click on a popular link.
4. Go back to about:newtab.
5. Observe scroll position.

**[Expected result]:**
- Scroll position is in the Popular links area.

**[Actual result]:**
- Scroll position is not maintained. (scroll position is on top of the page)
 
**[Regression range]:**
- Last good revision: 3004bc7597a088e181fbcb9a9044b8d952e9d45f
- First bad revision: 5b47cfcab1554c89400b7a6299ff0cabac4bda0c
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3004bc7597a088e181fbcb9a9044b8d952e9d45f&tochange=5b47cfcab1554c89400b7a6299ff0cabac4bda0c 

- Seems like Bug 1617983 stands out and might caused this behavior;

**[Additional notes:]**
- Reproducible also while clicking a Recommended by Pocket/ Highlight cards and coming back to the page;  
- No matter the value of the “browser.tabs.remote.separatePrivilegedContentProcess” pref (true/false) we encounter an old issue that stands for not keeping the scroll position **only the first time** a user comes back to the page.

@mconley can you please take a look on this?
Bug: [meta] [Epic/Meta] Quantum Bar design update 1 follow-ups
Status: NEW
Priority: P3
Created: 2020-04-15 14:49:15+00:00
Resolved: 2025-03-02 14:52:31+00:00

This Bugzilla holds all the Quantum Bar v1 bugs that will be fixed post Fx 75 release of QBv1 feature.
Bug: Content process fails to start if IAT is modified after the browser process's entrypoint
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-04-15 15:03:26+00:00
Resolved: 2020-05-01 09:46:09+00:00

The titled issue was mitigated as bug 1629361, but a user still hits the no-content-process situation once if a third-party application modifies IAT of firefox.exe after the browser process is launched.  A possible solution to this problem would be to cache IAT after process creation to copy to sandbox processes.
Bug: DoH rollout addon should disable itself if users make a choice about TRR
Status: RESOLVED
Priority: P1
Resolution: WORKSFORME
Created: 2020-04-15 17:20:08+00:00
Resolved: 2021-01-19 15:23:24+00:00

Current if a user in the DoH rollout switches away from the default TRR, the addon is still active for them. If users make a choice, the addon should yield all controls to users.
Bug: When using view image on a canvas, the resulting blob shouldn't live forever
Status: NEW
Priority: P3
Created: 2020-04-15 19:30:36+00:00
Resolved: 2024-09-25 13:15:41+00:00

Once bug 1626573 is fixed, we should be able to use a content principal for the blob URI we create for canvas images, by switching from `URL.createObjectURL` to `target.ownerGlobal.URL.createObjectURL`.
Bug: Showing the top sites underneath the address bar is redundant. When I open a new tab, it already gives me links to my top sites.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-15 20:29:16+00:00
Resolved: 2020-04-17 20:35:29+00:00

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

Steps to reproduce:

Open a new tab.


Actual results:

Top sites appear underneath the address. And also on the new tab page.
This is duplicate information and pushes down useful results in the address bar.


Expected results:

Top sites appear on the new tab page and that's it. Regular results from the address bar.