av9ash/GitBugs huggingface dataset:
Bug: Remove nightly-specific ifdefs in browser-menubar for preferences entrypoints on Windows and Linux
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2021-03-15 22:48:59+00:00
Resolved: 2021-03-30 03:53:56+00:00

See context in bug 1698577 / https://hg.mozilla.org/integration/autoland/rev/f7e6c28a8060 .
Bug: Don't leave users partially enrolled when they change one out of many prefs that are part of an experiment
Status: NEW
Priority: P3
Created: 2021-03-15 23:20:48+00:00
Resolved: 2021-03-15 23:28:50+00:00

Currently, if a user changes a preference that is being controlled by an experiment, Normandy unenrolls that user from the experiment and leaves the preferences as they are (so as not to override the value the pref just changed to). This behavior does not take into account that there are multiple preferences in some experiments.

For default-branch preferences, the preference remains sets to the experimental value for the rest of the Firefox session, and then is reset back to the original value the next time Firefox starts.

For user-branch preferences, the preferences remains set to the experimental value, and stays that way until some outside process changes it.

Neither of these outcomes are ideal. It leaves users in inconsistent and unstable states, and it makes it more difficult to reason about experiments.
Bug: AlpenGlow - tooltip for autohide in Customise page has right-border different than the rest
Status: NEW
Priority: P4
Created: 2021-03-16 08:40:21+00:00
Resolved: 2021-06-11 11:04:31+00:00

**Affected versions**
* 88.0a1(2020-03-15), 87.0;

**Affected platforms**
* Windows 10, macOS 11.3

**Steps to reproduce** 
1. Launch Firefox, access the Customize toolbar page;
2. Change to AlpenGlow theme;
3. Hover over the Downloads button (add it to toolbar before if not displayed);
4. Hover over the AutoHide tooltip;

**Expected result**
* tooltip properly displayed;

**Actual result**
* right border is not as rest of the lines for the tooltip;
* assumption: it might overlap with the search box doubling the intensity / transparency (moving it / the line clears);

**Regression range**
* First bad: 2020-08-21
* Pushlog: [URL](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=432e42cbbc4139efd2319952ec33efe8ff9add3c&tochange=369f72130f3604c85f73a3b03b2b48f33ad9b19e)
* Visible after bug 1643776, adding it to regressor field for tracking purposes;

**Additional notes**
* attached screenshot to illustrate the issue;
* might be better in Theme or another section, please reassign if so; as this issue does not happen on Dark/Light theme.
Bug: Context menus are missing block padding (need 4px spacing at the top and bottom between first/last visible item and the edge of the menu)
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-03-16 13:51:17+00:00
Resolved: 2021-03-23 09:38:07+00:00

The context menu is supposed to have 4px of block padding. So items are flush next to each other but the top/bottom items should have the 4px of space from the edge of the context menu.
Bug: uBlock Origin icon is no longer displayed on the toolbar when opening/closing the Customize page
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-03-16 13:55:31+00:00
Resolved: 2021-05-17 10:41:50+00:00

[Affected versions]:
Nightly (88.0a1/20210316094954)
Beta (87.0/20210315170302)
Release (86.0.1/20210310152336)

[Steps to reproduce]:
1. Install uBlock Origin. Notice that the add-on icon is added to the toolbar
2. Open a new tab
3. Right click on an empty space on the toolbar and select the “Customize...” option. The “Customize Firefox/Nightly” page is displayed.
4. Drag the add-on icon from the toolbar to the item list
5. Close the “Customize Firefox/Nightly” page
6. Open the “Customize Firefox/Nightly” page again by performing Step 3
7. Observe that the uBlock Origin add-on icon from the item list is no longer displayed (only the name of the add-on is visible)
8. Drag the add-on from the item list back to the toolbar (Notice that when hovering over the add-on on the toolbar, the tooltip tag is displayed)
9. Close the “Customize Firefox/Nightly” page
10. Observe that the add-on icon is still not visible in the position where it was placed in Step 8. Hovering over the add-on icon position will highlight the area and the tooltip tag will be displayed
11. Access https://www.youtube.com/ from the same tab
12. Notice that the add-on icon is visible again

[Expected results]:
The uBlock Origin icon should be visible in all instances.

[Actual results]:
The uBlock Origin icon is no longer displayed when the icon is dragged to the Customize toolbar item list and the Customize page is closed and reopened. Dragging the “invisible” icon back to the toolbar and closing the Customize page will keep the invisible state of the add-on icon.

The icon becomes visible again once a page where the add-on becomes active is accessed. Hence the 11th step above. 

It seems the issue occurs only on pages where the add-on is inactive i.e privileged Firefox pages (Add-ons Manager page, Options page, New Tab page etc.)

For further details, please also see the attached video.

Note: uBlock Origin appears to be the only affected add-on I could find at the moment.
Bug: [Cisco Webex] Microphone permission is leaked to other sites in the same tab during the grace period
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-03-16 14:49:55+00:00
Resolved: 2022-12-05 13:41:25+00:00

**Affected Versions:**
Nightly 88.0a1 (2021-03-16)

**Tested on:**
Windows 7/10 and MacOS

**Steps to Reproduce:**
1. Go to https://meet42.webex.com
2. Sign In (ask me on Slack for credentials if need be)
3. Start a meeting
4. Choose to join from browser
5. Grant access to the mic and webcam 
6. Click on start meeting
7. After the meeting is started navigate to any different site (youtube, 9gag, etc) or ones where microphone access is also needed (do this during the grace period)

For example, go to: https://mozilla.github.io/webrtc-landing/gum_test.html

8. Check the permission icon in the address bar and oberve microphone access is granted
9. Click on "Microphone" on the test page

**Expected Result:**
The microphone permission prompt should not leak into other sites permissions.

**Actual Results:**
Microphone permission is leaked to other sites in the same tab during the grace period.
Clicking on "Microphone" will also give access to the user's mic without any prompt for the test site.

**Regression-Range:**
Most likely regression of Bug 1693677. This is not reproducible if I disable the grace period.
We observed this issue only for this site during testing.
Bug: remote comcast study still active on non comcast firefox installation
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-03-16 14:53:26+00:00
Resolved: 2021-03-17 22:04:19+00:00

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

Steps to reproduce:

Download and upgrade or install the Firefox 87 build 2 rc. access about:support and you will see that there are active studies running that are directed for comcast users.


Actual results:

well if your not a comcast user then this should not be an active remote study. Also if you have studies disable via the pref in about:config you should not have any as well


Expected results:

without being a comcast user or have studies disabled you should not see this
Bug: Proton Normal and Touch mode icons in "customize toolbar" do not reflect the new design language
Status: NEW
Priority: P3
Created: 2021-03-16 16:00:20+00:00
Resolved: 2021-04-01 09:25:46+00:00

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

Steps to reproduce:

1. Update to the latest nightly
2. Notice the design language in the toolbar (the arrow icons specifically) for proton has changed 
3. Change density to touch or normal


Actual results:

When in the customize toolbar menu, the icons depicting density do not reflect the new design language. I.e. without the circle around the back button.


Expected results:

The density icons should reflect the new design language
Bug: Intermittent TEST-UNEXPECTED-TIMEOUT | browser/base/content/test/general/browser_bug623893.js | application timed out after 370 seconds with no output
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-03-16 17:44:42+00:00
Resolved: 2021-04-13 17:04:25+00:00

**Filed by:** abutkovits [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=333410687&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/CvpSrUAxRaCb2hihLwGqsA/runs/1/artifacts/public/logs/live_backing.log

---
```
[task 2021-03-16T17:09:16.895Z] 17:09:16     INFO - TEST-START | browser/base/content/test/general/browser_bug623893.js
[task 2021-03-16T17:15:29.911Z] 17:15:29     INFO - Buffered messages logged at 17:09:16
[task 2021-03-16T17:15:29.912Z] 17:15:29     INFO - Entering test bound test
[task 2021-03-16T17:15:29.912Z] 17:15:29     INFO - Buffered messages logged at 17:09:18
[task 2021-03-16T17:15:29.913Z] 17:15:29     INFO - TEST-PASS | browser/base/content/test/general/browser_bug623893.js | maintained the original index - 
[task 2021-03-16T17:15:29.913Z] 17:15:29     INFO - Buffered messages logged at 17:09:19
[task 2021-03-16T17:15:29.913Z] 17:15:29     INFO - TEST-PASS | browser/base/content/test/general/browser_bug623893.js | went back - 
[task 2021-03-16T17:15:29.913Z] 17:15:29     INFO - TEST-PASS | browser/base/content/test/general/browser_bug623893.js | went forward - 
[task 2021-03-16T17:15:29.914Z] 17:15:29     INFO - Buffered messages finished
[task 2021-03-16T17:15:29.915Z] 17:15:29    ERROR - TEST-UNEXPECTED-TIMEOUT | browser/base/content/test/general/browser_bug623893.js | application timed out after 370 seconds with no output
[task 2021-03-16T17:15:29.915Z] 17:15:29    ERROR - Force-terminating active process(es).```
Bug: The symbol bookmarks are not shown when you are already on a website. That is probably a very stupid bug and if not, it is a very stupid web design because it used to be different and better in earlier versions
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-03-16 18:20:17+00:00
Resolved: 2021-03-16 18:43:22+00:00

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

Steps to reproduce:

Open any website


Actual results:

The symbol bookmarks were hidden


Expected results:

The symbol bookmarks should not be hidden
Bug: Intermittent browser/components/urlbar/tests/browser/browser_switchToTab_closes_newtab.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-03-16 19:06:45+00:00
Resolved: 2021-04-13 17:04:28+00:00

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

---
```
[task 2021-03-16T17:01:39.884Z] 17:01:39     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_switchToTab_closes_newtab.js | Should have switched to the correct tab - [object XULElement] == [object XULElement] - 
[task 2021-03-16T17:01:39.884Z] 17:01:39     INFO - Leaving test bound test_switchToTab_closes
[task 2021-03-16T17:01:39.884Z] 17:01:39     INFO - Buffered messages finished
[task 2021-03-16T17:01:39.884Z] 17:01:39     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_switchToTab_closes_newtab.js | Test timed out - 
[task 2021-03-16T17:01:39.884Z] 17:01:39     INFO - GECKO(1564) | MEMORY STAT | vsize 130552468MB | residentFast 5164MB
[task 2021-03-16T17:01:39.885Z] 17:01:39     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_switchToTab_closes_newtab.js | took 325584ms```
Bug: Allow to open images in the current tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-16 19:54:15+00:00
Resolved: 2021-04-27 23:46:28+00:00

Bug 1690030 changed the context menu entry from "View Image" (in current tab) to "Open Image in New Tab". Previously, we had the option to open images both in the current tab (simple click) or in a new tab (ctrl-click or middle click).

In the new context menu, there is no way anymore to open the image in the current tab. A possible workaround would be to change ctrl-click behaviour to do so, since it currently does the same as a simple click and thus provides to added value.
Bug: Proton AppMenu is extremely difficult to read with Proton Dark theme enabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-03-16 20:49:53+00:00
Resolved: 2021-04-09 09:26:50+00:00

STR:

1. In Nightly, set `browser.proton.enabled` to `true`
2. Go to about:addons, switch to Themes, and enable Proton Dark
3. Open the AppMenu

ER:

A readable app menu.

AR:

See screenshot.

```
 9:51.07 INFO: No more integration revisions, bisection finished.
 9:51.07 INFO: Last good revision: ad40c13d6a3dc2f1a4817bd5f0d655c5ca5a81ab
 9:51.07 INFO: First bad revision: d54f1666473acafb01bbcb6d50846a8cf6a379d2
 9:51.07 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ad40c13d6a3dc2f1a4817bd5f0d655c5ca5a81ab&tochange=d54f1666473acafb01bbcb6d50846a8cf6a379d2
```
Bug: Focus rings are not visible in (at least) permission panels when Proton is enabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-03-16 22:35:01+00:00
Resolved: 2023-06-02 15:21:03+00:00

We've got focus rings on the checkboxes and menulists, but we appear to be missing them on the buttons.
Bug: Full-page-zoom indicator is too tall (fills the whole height of the address bar)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-16 22:48:40+00:00
Resolved: 2021-03-17 08:14:52+00:00

STR:
1. Ctrl + or Cmd + to zoom in on any site.
2. Look at the zoomlevel indicator at the right edge of your address bar.

ACTUAL RESULTS:
The indicator fills the entire height of the address bar, and its border runs up against the border of the address bar.

EXPECTED RESULTS:
There should probably be some padding around it (at least, there used to be padding around it, and that changed recently, which I'm guessing was by accident)

This is similar to bug 1696628 (and might've been regressed by the same change, I'm not sure)
Bug: The + button in tab strip is a bit taller than the tab itself while Drag Space is active
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2021-03-17 07:45:04+00:00
Resolved: 2021-04-08 12:49:25+00:00

**Affected versions**
- Firefox 88.0a1

**Affected platforms**
- macOS 10.15.7
- Ubuntu 20.04
- Windows 10

**Steps to reproduce**
1. Launch Firefox
2. Access customize and activate "Drag Space"
3. Hover over the + button in the tab strip

**Expected result**
- The tabs and + button has same height

**Actual result**
- The + button is a bit longer than the tab itself

**Regression range**
- Will see for a regression.

**Additional notes**
- The issue can be seen in the attachment
Bug: Error when translating etp tooltip in browser.xhtml
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-03-17 09:34:04+00:00
Resolved: 2022-09-08 08:00:51+00:00

I'm seeing this message in the browser console, when starting Firefox Nightly with the default locale. Looks like some fluent template has an error?

[fluent-dom] While translating an element with fluent ID "protections-panel-not-blocking-why-etp-on-tooltip" a child element of type "description" was removed. Either the fluent message does not contain markup, or it does not contain markup of this type.
Bug: [macOS VoiceOver] The Screen Reader has inconsistent behaviour with the webRTC permission panel
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-03-17 09:37:55+00:00
Resolved: 2023-06-02 15:21:03+00:00

**Affected Versions:**
All latest Firefox versions

**Tested on:**
MacOS

**Steps to Reproduce:**
1. Enable the macOS screen reader before starting Firefox 
2. Go to https://mozilla.github.io/webrtc-landing/gum_test.html
3. Use Option+Command+Right Arrow to navigate along with the screen reader to the Microphone&Camera button
4. Follow the voiceOver guidance to pres the button (Option+Command+Space) or hit Enter

**Expected Result:**
As soon as the permission prompt is displayed, the voice-over should start reading out loud all the content from the prompt (such as with NVDA on Windows)

**Actual Results:**
2 possible behaviors, inconsistent :
- Only the question is detected by the screen reader: "Allow mozilla.github.io to use your camera and microphone?"
- Everything is detected correctly: question, camera label, microphone menulist, etc

**Note:**
After refreshing the page and following again the steps the screen reader will not detect the toggled permission prompt at all, see attached screenshot. 

**Regression-Range:**
Reproducible on FX 86, also intermittently. There are 2 bugs here (from which 1 is intermittent) and the refresh page aspect mentioned in *notes* is also causing troubles narrowing the regression-range. Not related to Proton changes.

**Severity:**
Marking this as S2 given a11y is an important area to cover and at this point the webRTC prompt might not be functional for screen reader users. Please feel free to change the severity if need be after further investigations, I assume people who use screen readers on a daily basis will have a more technical and in-depth analysis of the severity for this issue.
Bug: [Linux Orca] The Screen Reader has an incorrect behaviour with the webRTC permission panel
Status: RESOLVED
Priority: P2
Resolution: MOVED
Created: 2021-03-17 10:19:20+00:00
Resolved: 2022-01-05 16:44:24+00:00

**Affected Versions:**
All latest Firefox versions

**Tested on:**
Ubuntu Linux

**Steps to Reproduce:**

1. Enable the Ubuntu screen reader before starting Firefox
2. Go to https://mozilla.github.io/webrtc-landing/gum_test.html
3. Click the Microphone and Camera test button

**Expected Result:**
As soon as the permission prompt is displayed, the voice-over should start reading out loud all the content from the prompt (such as with NVDA on Windows).

**Actual Results:**
The reader just says "Alert" and then no further reading is done for the prompt.

**Note:**
After refreshing the page and following again the steps the screen reader will not detect the toggled permission prompt at all, see attached screenshot.
The screen reader will fully read the prompt only if you interract with it (like if you have multiple devices connected and can interract with the dropdown). If the prompt is a label it will not be read.

**Regression-Range:**
Reproducible on FX 86 and beta 87 but with a slightly different outcome since only the question is detected by the screen reader: "Allow mozilla.github.io to use your camera and microphone?"

**Severity:**
Marking this as S2 given a11y is an important area to cover and at this point the webRTC prompt might not be functional for screen reader users. Please feel free to change the severity if need be after further investigations, I assume people who use screen readers on a daily basis will have a more technical and in-depth analysis of the severity for this issue.
Bug: Address bar chiclet icons don't have a contrast with Proton default theme
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-17 10:31:43+00:00
Resolved: 2021-03-25 02:15:34+00:00

[Note]:
- Recent Proton regression affecting Urlbar chiclet icons, in unfocused state

[Affected versions]:
- latest Nightly 88.0a1 20210316214855

[Affected platforms]:
- Win 10 64-bit
- Mac OSX 10.15

[Steps to reproduce]:
0. Enable Proton address bar preferences: 
browser.proton.enabled
browser.proton.toolbar.enabled
browser.proton.urlbar.enabled
1. Open about:support in the address bar (or any other About: page)
2. Observe the address bar.	
3. Open address bar and select a search shortcut - search mode opens
4. Focus something in page and observe the search-mode button and it's styling.

[Expected result]:
2. 4. Firefox icon chiclet (search mode indicator) is signaling that the open address is a Firefox address, matches figma https://www.figma.com/file/FjUe6ORvXZgJvI3rPuTV33/Desktop-UI-(Mozilla-Confidential-)?node-id=1729%3A66576 design 

[Actual result]:
2. 4. Address bar chiclet icons don't have a contrast while the address bar is unfocused 

[Regression range]:
- 2021-03-17T10:56:39.508000: DEBUG : Found commit message:
Bug 1698499 - Simplify --toolbarbutton-{hover/active}-background and --toolbarseparator-color implementation. r=harry

Differential Revision: https://phabricator.services.mozilla.com/D108433

[Additional notes]:
- Nightly without Proton is not affected
- (Proton) Dark & Light themes are not affected, see the attachment 
- Reproduces also when all the Proton prefs are enabled
Bug: Opening settings page right after browser start-up shows white textbox for a few ms
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2021-03-17 11:31:50+00:00
Resolved: 2021-04-05 11:10:32+00:00

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

Steps to reproduce:

1. Open Firefox.
2. Open Settings right away!


Actual results:

1. The painting of the screen is a bit slow.
2. Icons show up a few ms after.
3. The search textbox is white for a few ms.


Expected results:

1. The search textbox is white for a few ms.
See attached video.
Bug: Copy URL via URL Page actions is gone
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-03-17 11:40:00+00:00
Resolved: 2021-05-02 10:19:20+00:00

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

Steps to reproduce:

Open browser navigate to any page
Observe the content of Page actions menu


Actual results:

"Page actions" menu doesn't have "copy URL" item
Prior to Nightly 88 this item was present in the "Page actions" menu.


Expected results:

"Copy URL" should be present in the Page actions menu.
When pinned to URL bar this feature allows users to copy Current tab URL via a single mouse click.
After it was removed to achieve the same task user needs to focus on URL bar, then Right click on it, select "copy" from the dropDown menu. This takes significantly more time for the user when compared to the old behavior.
Bug: Can't view images in same tab anymore
Status: VERIFIED
Priority: P3
Resolution: WONTFIX
Created: 2021-03-17 13:24:57+00:00
Resolved: 2024-03-28 05:17:33+00:00

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

Steps to reproduce:

Follow-up to Bug 1690030, which made it so that the "View image" button in the context menu when right-clicking on an image is replaced by a "View image in new tab" button.


Actual results:

There is no longer a way to open an image in the same tab.


Expected results:

There should be some way to still open an image in the same tab. In his comment at https://bugzilla.mozilla.org/show_bug.cgi?id=1690030#c8, Neil suggested re-utilizing the common CTRL+click/middle mouse shortcut on the button to open the image in the same tab, but since those keys are almost universally regarded as a new window/new tab shortcut, I believe this would be somewhat unintuitive.

I would prefer a new about:config preference that switches the default behaviour for the "View image" button in the context menu. Personally, I have been using the middle mouse on the "View image" button to open an image in a new tab for so long that I'd prefer not having to retrain my muscle memory.