av9ash/GitBugs huggingface dataset:
Bug: Can't log into Grafana
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-02 23:50:54+00:00
Resolved: 2020-06-03 00:05:01+00:00

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

Steps to reproduce:

Log into grafana. Response:

HTTP/1.1 200 OK
Server: nginx/1.16.1
Date: Tue, 02 Jun 2020 23:46:44 GMT
Content-Type: application/json
Content-Length: 49
Connection: keep-alive
Cache-Control: no-cache
Expires: -1
Pragma: no-cache
Set-Cookie: grafana_session=; Path=/grafana; Max-Age=0; HttpOnly; Secure
Set-Cookie: grafana_session=a4e7ff4a2c8b0b92445d98700b5d24b0; Path=/grafana; Max-Age=2595600; HttpOnly; Secure
Set-Cookie: redirect_to=; Path=/grafana; Max-Age=0; HttpOnly; Secure



Actual results:

Redirected back to the login page, cookie is cleared:

HTTP/1.1 302 Found
Server: nginx/1.16.1
Date: Tue, 02 Jun 2020 23:46:44 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 37
Connection: keep-alive
Cache-Control: no-cache
Expires: -1
Location: /grafana/login
Pragma: no-cache
Set-Cookie: grafana_session=; Path=/grafana; Max-Age=0; HttpOnly; Secure
Set-Cookie: redirect_to=%2Fgrafana%2F; Path=/grafana; HttpOnly; Secure

Server logs
Jun 03 09:46:44 prometheus grafana-server[130278]: t=2020-06-03T09:46:44+1000 lvl=info msg="Successful Login" logger=http.server User=boden
Jun 03 09:46:44 prometheus grafana-server[130278]: t=2020-06-03T09:46:44+1000 lvl=eror msg="Failed to look up user based on cookie" logger=context error="user token not found"



Expected results:

Stay logged in.
Works in Chrome and Edge without issues, only Firefox nightly is affected.
Bug: CTRL+W is attempting to close all tabs vs. open tab or window (pop-up email window).
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-03 04:05:58+00:00
Resolved: 2024-03-04 13:59:30+00:00

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

Steps to reproduce:

A little less than an hour ago, I updated to the newest version of Firefox, restarted the browser, went into my email.  I clicked on the email and I have it set to pop out into a new window when reading/writing emails.  Once I tried to close the pop-out window, bug occurred.


Actual results:

I hit CTRL+W to close the email window when I was finished, and it tries to close the entire window and/or all open tabs vs. only the popped-out email window.  I have NEVER had this issue before this FF update, and I can't reproduce with anything else because it's an email pop-up.  I don't know if it's associated with the email tab or not.  I've made no changes to any other settings on my computer, keyboard, email settings or otherwise.  I only updated Firefox in the last hour.


Expected results:

Only the email window should close with the keyboard shortcut CTRL+W.  No other tabs, not the entire window browser.
Bug: Right click on text in search box brings up incomplete context menu
Status: RESOLVED
Priority: P4
Resolution: FIXED
Created: 2020-06-03 06:16:51+00:00
Resolved: 2020-10-26 14:51:35+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:

1) open new tab with empty page
2) click search box, type in some text
3) click somewhere on the empty page
4) right click on the search box (doesn't matter, text or empty space)
NOTE: It seems that the issue only appears on MacOS. Broken since (approximately) v75.


Actual results:

Text in search box becomes selected, text context menu appears with options "cut", "copy" and "delete" inactive. In order to make them active you need to right-click the selected text in search box again.


Expected results:

Text in search box becomes selected, text context menu has options "cut", "copy" and "delete" active right away.
Bug: Test names in mochitest.sh are incorrect
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-06-03 06:31:57+00:00
Resolved: 2020-06-04 15:37:05+00:00

At least one test name in `browser/components/newtab/mochitest.sh` is incorrect, referring to a test that has been renamed. Now it appears this test is not covered by this script.

`browser_new_tab_in_privileged_process_pref.js` has been renamed to `browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js`.
Bug: URL Bar expands in Firefox 77 even though this is disabled in about:config
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-03 08:00:03+00:00
Resolved: 2020-06-06 11:59: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:

Click on url bar in Firefox 77


Actual results:

Url bar expanded


Expected results:

url bar does not expand

(expand is disabled through settings in about:config since Firefox 75 or so...
new setting browser.urlbar.update2.expandTextOnFocus is disabled (the default) but is not recognized)
Bug: Address bar intranet subdomains searched instead of opened
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-06-03 09:12:20+00:00
Resolved: 2021-04-07 12:54:34+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 my intranet subdomain app.env.company.loc into address bar without http:// in front (have separate address and search bars) instead of opening it as it did in FF76 now it searches google instead.  Did not find mention of this channge in whats new. 
And cant find a way of dissabling this behavior, other than one by one whitelisting them, which is not feasable with hunderds of them.




Actual results:

Searched google instead of opening subdomain


Expected results:

Open  webapplication on intranet.
Bug: using backspace to remove website data closes the modal window
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2020-06-03 12:59:56+00:00
Resolved: 2023-04-13 07:52:10+00:00

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

Steps to reproduce:

1. Go to Preferences -> Privacy & Security -> Cookies and Site Data -> Manage Data...
2. select a domain from the list
3. press backspace


Actual results:

either:
1. closes the modal window
2. keeps modal window open and navigates back to `General Preferences`


Expected results:

remove domain from list
Bug: Intermittently hitting enter on a URL fails to navigate
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2020-06-03 13:00:22+00:00
Resolved: 2020-08-14 17:06:33+00:00

Some low percent of the time, if I CMD-Tab to firefox, hit CMD-L, then type a partial url then hit enter, Firefox fails to navigate to the URL. 

Apologies for the vague low information bug report, but I'm not what's the best information I can gather next time this happens. Unfortunately, it is the kind of bug that I only slowly started noticing after subconsciously working around it for some time. 

Some notes from the most recent occurrence: 

* I have a newtab extension, and I notice that when I realized that we'd failed to navigate the tab was a blank grey box, without the newtab extension or about:newtab.
* I typed maybe two characters before hitting enter, as I was headed to my inbox which is one of my top visited urls, and so it completed very quickly.
Bug: [RTL] The background gradient color of the `.monitor-blocks` is facing the wrong way
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-06-03 13:48:13+00:00
Resolved: 2020-07-02 14:38:00+00:00

Related code:
https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/browser/components/protections/content/protections.css#837,842,847
Bug: The overlay disappears when being minimized in Windows
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-06-03 14:21:05+00:00
Resolved: 2021-12-12 22:26:48+00:00

**Note**
* The overlay disappears when the user minimizes it.

**Affected versions**
* Nightly v78.0a1 from 2020-05-27

**Affected platforms**
* This issue only occurs on Windows.
* The macOS handles minimization well and the Linux minimize button does not work

**Steps to reproduce**
Required prefs:
* Flip privacy.webrtc.allowSilencingNotifications to true
* Flip privacy.webrtc.legacyGlobalIndicator to false

1. Engage in a video call.
2. Allow camera or microphone permissions (to make the overlay visible)
3. Click the minimize button.

**Expected result**
* The overlay minimizes correctly and can be brought back up from the taskbar.

**Actual result**
* The overlay disappears and cannot be brought back up in the same call.

**Regression range**
* This is a recent regression.
Bug: The overlay is incorrectly displayed while in a high contrast theme on windows
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2020-06-03 14:22:29+00:00
Resolved: 2021-12-12 22:27:42+00:00

**Note**
* When the user has a High Contrast theme set and engages in a conference call, he will notice that the Global Sharing Overlay is improperly displayed.

**Affected versions**
* Nightly v78.0a1
* Beta v77.0 (RC)

**Affected platforms**
* Windows only
* the default high contrast features on Mac and Linux, does not affect how the overlay's general appearance

**Steps to reproduce**
Required prefs:
* Flip privacy.webrtc.allowSilencingNotifications to true
* Flip privacy.webrtc.legacyGlobalIndicator to false

1. Apply a high contrast theme from OS settings.
2. Engage in a video conference on ant WebRTC web-app.
3. Observe the Global Sharing Overlay.

**Expected result**
* It is properly displayed.

**Actual result**
* The buttons became severely contrasted with the rest of the overlay frame.

**Regression range**
* This is a feature implementation issue.
Bug: The Global Sharing Indicator buttons' hover state is not working properly on windows and linux
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-06-03 14:25:24+00:00
Resolved: 2020-06-19 14:05:22+00:00

**Note**
* When the user shares the microphone and/or the camera and hovers over the Global Sharing Indicator's buttons, he will notice that the hover is not functioning correctly.
* More exactly, in some situations, the hover state remains ON when it should not. 
* In the video, it can be noticed that leaving the button area in a direction where the button does not have a frame, the hover state will remain activated incorrectly.

**Affected versions**
* Nightly v78.0a1
* Beta v77.0 (RC)

**Affected platforms**
* Windows 10
* Ubuntu 18.04.4 LTS
* does NOT occur on MacOS

**Steps to reproduce**
Required prefs:
* Flip privacy.webrtc.allowSilencingNotifications to true
* Flip privacy.webrtc.legacyGlobalIndicator to false

1. Engage in a conference call.
2. Allow permissions for camera and microphone.
2. Hover over the Overlay's buttons.

**Expected result**
* The hover state works correctly.

**Actual result**
* The hover state remains activated incorrectly in some situations.

**Regression range**
* This is a recent regression. Please NI me if you need the exact pushlog of the issue's introduction.
Bug: The Global Sharing Indicator's button colors are not according to design
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-03 14:26:49+00:00
Resolved: 2021-12-12 22:57:21+00:00

**Note**
* The Camera and Microphone buttons are a shade darker than the rest of the overlay's frame. They should have the same color as the frame, unless the design changes.
* Only the minimize button has a darker shade than the rest of the overlay.

**Affected versions**
* Nightly v78.0a1
* Beta v77.0 (RC)

**Affected platforms**
* ALL

**Steps to reproduce**
Required prefs:
* Flip privacy.webrtc.allowSilencingNotifications to true
* Flip privacy.webrtc.legacyGlobalIndicator to false

1. Engage in a video conference.
2. Share the microphone and camera, preferably the screen, also.
3. Observe the Overlay's default color.

**Expected result**
* The camera and microphone buttons should be the same color as the frame; only the minimize button should be darker.

**Actual result**
* The camera and microphone have a slightly darker color, like the minimize button.

**Regression range**
* This is an implementation issue.

**Additional notes**
* This issue could be worked-around along with bug 1641620 and bug 1640203 if a nice looking border would be implemented around the whole Overlay.
Bug: Screen sharing permission door-hanger has a drop-down option without a string when a confidential bug is loaded and focused in any browser
Status: NEW
Priority: P3
Created: 2020-06-03 14:30:16+00:00
Resolved: 2020-11-03 17:38:42+00:00

Note

Screen sharing permission door-hanger has a drop-down option without a string.

Affected versions

Nightly v78.0a1

Affected platforms

Windows 10

Steps to reproduce
Required prefs:

Flip privacy.webrtc.allowSilencingNotifications to true
Flip privacy.webrtc.legacyGlobalIndicator to false

1. Open a confidential bug from Bugzilla on Chrome and let the tab on focus.
2. Go to Nightly and start a Video Call in the expected web-app(Talky).
3. Click the button to share your screen view.

Expected result

All options from screen sharing permission door-hanger should have a string name

Actual result

Screen sharing permission door-hanger has a drop-down option without a string name.

Regression range

It is not feature-related. This bug is reproducible on Firefox Release and Firefox Beta

Additional notes

This issue has been found to reproduce with Talky on Windows 10.
This bug description will suffer changes (updates) until the feature testing is completed.
Bug: [UX] The "Mute Mic" and "Mute Camera" buttons open the "Permissions" tab instead of muting the mic/camera
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2020-06-03 15:08:19+00:00
Resolved: 2025-02-14 19:19:52+00:00

[Affected Versions]:
- Nightly 79.0a1
- Firefox Beta 78.0b1
- Firefox 77 RC-build 3

[Affected Platforms]:
- All Windows;
- All Mac;
- All Linux;

[Prerequisites]:
- The following preferences are set:
	-> privacy.webrtc.allowSilencingNotifications = true
	-> privacy.webrtc.legacyGlobalIndicator = false
- Have at least 2 tabs opened.

[Steps to reproduce]:
1. Open the browser with the profile from prerequisites.
2. Start a webRTC video call on Zoom and share the entire screen.
3. Click the "Mute Mic"/"Mute Camera" button from the Global Sharing Indicator.
4. Observe the behavior.

[Expected results]:
- The mic/camera is muted.

[Actual results]:
- The "Permissions" tab is opened

[Notes]:
- Attached a screen recording of the issue.
Bug: Megabar and possible HIPPA concerns
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-03 16:42:11+00:00
Resolved: 2020-06-08 20:18: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:

The new Megabar expands and displays topsites, searches, and other bookmarks that might be a problematic in the workplace where Hippa is concerned.

Context: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html


Actual results:

As a IT Manager we held a meeting to address the new Megabar and concerns that too much private information can be displayed by using the new Megabar. As it exposes search results, frequently visiting sites, Topsites, and other URLs that might contain personal information within the URL by onlookers or passer bys which is a violation of the HIPPA laws for my work place.


Expected results:

Results of that meeting it was decided that it needed to be disabled, however this is not possible in normal conventional ways. As a work around we have implemented that all computers in the Hospital must use a userchrome.css with the CSS that can disable this function until a better method is discovered. Using another browser was voted down as the amount of man power to reimage over 700 machines was to costly and could effect patients negatively.
Bug: save to pocket button not visible even though pref is true
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2020-06-03 16:52:53+00:00
Resolved: 2020-06-16 11:14:28+00:00

The profile this is happening in is from Poland. On nightly.

It looks like an uncaught js error is causing the pocket button to not finishing or start instantiating.

The js error is localization related.

The main error that's causing the Pocker button to fail is `NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.formatStringFromName] SaveToPocket.jsm:272`

There are a few other l10n errors in the console that I thought might be related, and they are:

`[fluent] Missing translations in en-GB: urlbar-default-placeholder, urlbar-permissions-granted, urlbar-remote-control-notification-anchor, urlbar-switch-to-tab, urlbar-extension, urlbar-placeholder, urlbar-go-button, urlbar-page-action-button, urlbar-pocket-button. Localization.jsm:202:13`

and

`No localization found for [webconsole.input.editor.onboarding.dismiss.label] l10n.js:130:13`

The last one has a call stack which I have a screen shot for and I'll add as an attachment.

There is a bit there about en-GB in one of the errors. I think that's unrelated, but never know. We were changing some stuff in the profile when we started to debug, and one of those was to play around with the region/locale. That might be why it's reporting en-GB there.
Bug: The issue is when I am searching on google a specific term firefox is showing weird behavior.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-03 17:10:03+00:00
Resolved: 2020-06-29 20:02:43+00:00

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

Steps to reproduce:

I searched on google the term:
Lookup error: *******************************************************************************************************************************************************************************************************************************************************************************************************************************.


Actual results:

The result was when the next screen loaded the firefox window gets hanged for which I need to force shut down the firefox and restart it once again. 
I tried multiple number of times but the same behavior is reported again and again.


Expected results:

The search result should be shown when I click on search and the firefox should not hang.
Bug: Normandy initialize is called twice with --first-startup
Status: RESOLVED
Priority: P1
Resolution: WONTFIX
Created: 2020-06-03 17:33:12+00:00
Resolved: 2022-07-28 14:58:27+00:00

When Firefox is run with the `--first-startup` flag, such as when a new version is installed, Normandy's initialization sequence is triggered twice. First by `FirstStartup.jsm`, and second by `BrowserGlue.jsm`.

This  is definitely wrong, and has caused on specific problem that we know of. If a rollout is active, it will be graduated immediately, since the second initialization will see the results of the first.

Normandy's initialization sequence should be idempotent.
Bug: Pioneer icon is hard to see in dark mode "What happens next?" section
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-06-03 19:43:17+00:00
Resolved: 2020-07-01 12:54:27+00:00

The pioneer icon in the "What happens next?" section is dark-on-dark when in dark mode. The icon should be filled the same as the text to avoid this issue.

```
.pioneer-icon {
  -moz-context-properties: fill;
  fill: currentColor;
}
```
Bug: Twitches when searching over setting
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-03 20:13:05+00:00
Resolved: 2020-06-04 14:57:39+00:00

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

Steps to reproduce:

There are twitches when searching over setting.
It makes eyes tired.
Since there is no reason to move elements on the page when they are highlighted in yellow, it would be reasonable to avoid this side effect.

See how to reproduce it here:
https://www.youtube.com/watch?v=1BDn62uHYFg


Actual results:

- elements are moved from its initial place


Expected results:

- elements are stayed at the same position without any movement
Bug: Obey prefers-reduced-motion in EME shaky icon
Status: NEW
Priority: P3
Created: 2020-06-03 21:25:26+00:00
Resolved: 2020-06-24 17:23:40+00:00

https://searchfox.org/mozilla-central/rev/7cadba1d8b8feaec4615f5bb98aac4b8a719793c/browser/themes/shared/notification-icons.inc.css#262-273

should probably be in a media query. Though I wonder if we should have some kind of alternative for people with that pref, to still highlight the first time they play EME media.
Bug: klsihk64.dll still causes crash because BLOCK_WIN8_ONLY is not working
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-06-03 23:54:27+00:00
Resolved: 2020-06-12 17:57:02+00:00

Because a new blocklist (bug 1445025) compares OS version incorrectly, the flag `BLOCK_WIN8_ONLY` does not block anything.  As a result, crashes in klsihk64.dll (bug 1268470) reappears.
Bug: 2-lines layout is not used consistently
Status: NEW
Priority: P5
Created: 2020-06-04 01:04:48+00:00
Resolved: 2020-06-05 09:02:38+00:00

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

Steps to reproduce:

1. Open Firefox with a clean profile. This is required for the next step.
2. Set the window size at 1030x800.
3. Type "m" in the urlbar.
4. Unfocus then refocus the urlbar.


Actual results:

At step 3 the results are presented in one line. At step 4 the same results are presented in two lines.


Expected results:

For a given window size the search results of the urlbar should always use either one or two lines.
Bug: DNS over HTTP activated when GUI says it's off
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-04 04:05:31+00:00
Resolved: 2020-06-08 15:26:13+00:00

Steps to reproduce:

According to the user, normal browser use.

This morning, a Windows PC running Firefox 77.0.1 effectively attacked my web proxy by trying to access DNS-over-HTTPS server 250x/sec (Bug 1643228 suggests less aggressive behavior)

Actual results:

The Settings GUI showed that DNS-over-HTTPS was disabled (and user never asked for it to be enabled). Setting & clearing the option did nothing until I exited Firefox and went back in; at that point, it stopped trying to use the feature.

Expected results:

DNS-over-HTTPS should not spontaneously enable itself on an established installtion.
The GUI should accurately reflect the state of the feature; if GUI says it's disabled, it should be disabled.
Bug: Dark theme - addons icon on SessionRestore needs color change to improve visibility
Status: NEW
Priority: --
Created: 2020-06-04 06:23:09+00:00
Resolved: 2022-10-12 00:10:08+00:00

**Affected versions**
* 78.0b2, 79.0a1

**Affected platforms**
* macOS 10.15.5, Windows 10

**Steps to reproduce**
1. Set Firefox to dark theme;
2. Access (in tab1) about:addons
3. In another tab(tab2) access any webpage 
4. Access (in tab1) about:crashparent
5. Ok on all windows so browser restarts;
6. Reopen tab2 and access about:addons again;
7. access (in tab1) about:crashparent and have browser restart again.

**Expected result**
* icon for internal pages is visible;

**Actual result**
* poor contrast between background and icon as opposed to icon for Window1

**Regression range**
* will check and provide one asap;

**Additional notes**
* attached screenshot with the issue.
Bug: Duplicate history entries
Status: NEW
Priority: P3
Created: 2020-06-04 07:47:34+00:00
Resolved: 2020-06-19 02:25:32+00:00

about:sync in one of my test accounts has:

```
{"id":"RVp-jMzDgC1V","histUri":"http://example.com/","title":"Example Domain","visits":[{"date":1589925960960000,"type":1},{"date":1585722252070000,"type":2}]}	"RVp-jMzDgC1V"	"http://example.com/"	"Example Domain"	[{"date":1589925960960000,"type":1},{"date":1585722252070000,"type":2}]
{"id":"9bpWBjdVNEeT","histUri":"http://example.com/","title":"Example Domain","visits":[{"date":1589925960960000,"type":1},{"date":1585722252070000,"type":2}]}	"9bpWBjdVNEeT"	"http://example.com/"	"Example Domain"	[{"date":1589925960960000,"type":1},{"date":1585722252070000,"type":2}]
```

These should have been reconciled. Not sure if this is desktop or app-services (both recently wrote to history)