av9ash/GitBugs huggingface dataset:
Bug: Enhanced Tracking Protection milestone doorhanger shows incorrect date
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-01-02 23:38:09+00:00
Resolved: 2024-01-22 15:08:14+00:00

This was mentioned by a German localizer and I was able to reproduce on my machine locally.

The string `cfr-doorhanger-milestone-heading2` should display that X number of trackers were blocked since the user profile began tracking blocked counters, e.g. `Nightly blocked over 1,000 trackers since May 2023!`. Instead, the string is displaying the current month and year (`Nightly blocked over 1,000 trackers since January 2024!`)

Steps to reproduce:
1) Create a new profile and open in Firefox
2) Visit a page with a tracking cookie (recommend `amazon.com`). This will create an entry in `protections.sqlite`
3) Use `about:support` to find the Profile Folder where your `protections.sqlite` file is saved
4) Quit Firefox to ensure `protections.sqlite` is editable
5) Use a sqlite database editor such as `DB Browser for SQLite` to open `protections.sqlite`
6) Find the first entry in the `events` table, edit the `count` column to `1000`, and the `datetime` column to something other than January 2024 (e.g. `2023-11-03`). Write the changes to the database and close your editor.
7) Open Firefox with the profile created in step 1
8) Navigate to `about:config`, create and set a config `browser.contentblocking.cfr-milestone.update-interval` and set the value as a number `10`
9) Navigate to `amazon.com`. Refresh the page until the string is triggered. (Should take around 3 refreshes.)
10) Observe the doorhanger (screenshot attached)

Similar strings (`graph-total-tracker-summary` and `protections-milestone`) show the date of earliest recorded blocked trackers as expected.

I've checked a previous bug (Bug 1687910) in which this string was changed, but was this fixed more than 3 years ago, so something must have changed in the code calling this string.
Bug: Success message is not announced by VoiceOver when a report is successfully submitted via new Report Broken Site
Status: NEW
Priority: --
Created: 2024-01-03 00:27:50+00:00
Resolved: 2024-01-29 16:50:10+00:00

### STR:
1. Ensure VoiceOver is running
1. From any site, open a new `Report Broken Site` tool (i.e. via URL bar > Enhanced Tracking Protection > Report Broken Site) with keyboard by using VO keys + Arrow keys (VO are `ctrl`+`opt` usually)
1. Fill in the form with test data
1. Navigate to and press `Send` button with `VO` + `Space` keys
1. Observe the announcement of a screen reader

### Expected: 
1. Screen reader is announcing that the report is successfully sent, the screen reader announces the success message, at minimum the text that is visually a title of the dialog: `Success: Your report has been sent` 

### Actual:
1. Screen reader only announces the `Okay, button` (where the focus is placed), all of the above content that includes essential status data of the report is ignored and, unless the user would move the screen reader focus backwards (in browse mode, with arrow up), they would likely miss the status message altogether
Bug: Firefox View longer typed terms will extend the search results box out of view in History section
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-01-03 13:21:56+00:00
Resolved: 2024-01-17 08:15:25+00:00

**Found in**
- Firefox 123.0a1

**Affected versions**
- Firefox 123.0a1

**Tested platforms**
- Affected platforms: macOS 13.6.3, Windows 11, Ubuntu 22.04

**Steps to reproduce**
1. Launch Firefox and access Firefox View
2. Open the History section
3. Focus search and type any word/website
4. Copy the typed word and paste it multiple times inside search

**Expected result**
- The search results box / import history message retains their width in page when longer strings are typed

**Actual result**
- Both the search results box and import history message gets stretched out of view

**Additional notes**
- The issue can be seen in the [attachment](https://drive.google.com/file/d/1XoxbqnEn14Pyi0txzdT0gUne-v9RRb0P/view?usp=sharing)
Bug: Firefox View test failure for search_synced_tabs_recent_browsing due to not all search results showing.
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2024-01-03 21:06:28+00:00
Resolved: 2024-01-18 17:38:55+00:00

`search_synced_tabs_recent_browsing` is failing on central currently. See below test output.

```
browser/components/firefoxview/tests/browser/firefoxview-next/browser_syncedtabs_firefoxview_next.js
  FAIL Uncaught exception in test bound search_synced_tabs_recent_browsing - Not all search results are shown yet. - timed out after 50 tries.
```
Bug: [Protections Panel] Protections doorhanger has a blocked tracker milestones subviewbutton that is unlabeled
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-01-04 00:48:04+00:00
Resolved: 2024-02-01 00:17:03+00:00

The Protections doorhanger UI includes [a subview button with id `protections-popup-milestones-content`](https://searchfox.org/mozilla-central/rev/762f24e00a9548d80ebba1b985c871ba6d9b829d/browser/components/controlcenter/content/protectionsPanel.inc.xhtml#160-167) that does not provide an accessible name, 

It appears to happen because this `<toolbarbutton>` XUL control is marked up with [`<description>` as its child containing the on-screen text](https://searchfox.org/mozilla-central/rev/762f24e00a9548d80ebba1b985c871ba6d9b829d/browser/components/controlcenter/content/protectionsPanel.inc.xhtml#164-165), while `<label>` does provide an expected output for the Accessibility API preserving its visual appearance at the same time.

When this bug is resolved, we need to remove [the `fail-if` notation](https://searchfox.org/mozilla-central/rev/762f24e00a9548d80ebba1b985c871ba6d9b829d/browser/base/content/test/protectionsUI/browser.toml#57) from the `browser/base/content/test/protectionsUI/browser_protectionsUI_milestones.js` test manifest.

Note: the following prefs are needed:
```
      // Hide protections cards so as not to trigger more async messaging
      // when landing on the page.
      ["browser.contentblocking.report.monitor.enabled", false],
      ["browser.contentblocking.report.lockwise.enabled", false],
      ["browser.contentblocking.report.proxy.enabled", false],
      ["browser.contentblocking.cfr-milestone.update-interval", 0],
```


A11y_checks output is the following:
```
Result	Path	Error	El ID	El tagName	El className	Stack trace
FAIL	browser/base/content/test/protectionsUI/browser_protectionsUI_milestones.js	Interactive elements must be labeled	protections-popup-milestones-content	toolbarbutton	subviewbutton	"
chrome://mochikit/content/browser-test.js:test_ok:1583
chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:a11yFail:339
chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:assertLabelled:510
chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:assertCanBeClicked:670
chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:runIfA11YChecks/this.AccessibilityUtils:635
chrome://mochikit/content/tests/SimpleTest/AccessibilityUtils.js:handleClick:751
chrome://mochikit/content/tests/SimpleTest/EventUtils.js:synthesizeMouseAtPoint:652
chrome://mochikit/content/tests/SimpleTest/EventUtils.js:synthesizeMouse:555
chrome://mochikit/content/tests/SimpleTest/EventUtils.js:synthesizeMouseAtCenter:740
chrome://mochitests/content/browser/browser/base/content/test/protectionsUI/browser_protectionsUI_milestones.js:doTest:78
chrome://mochikit/content/browser-test.js:handleTask:1134
chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1206
chrome://mochikit/content/browser-test.js:Tester_execTest:1348
chrome://mochikit/content/browser-test.js:nextTest/<:1123
chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058
"
```
Bug: Certificate Manager popup doesn't grow with content
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-01-04 11:05:26+00:00
Resolved: 2024-01-29 16:07:37+00:00

I noticed a little hiccup in the UI.
`about:preferences#privacy -> View certificates...`
I added a few exceptions and the buttons went off the popup.
I had to close it using the X and then reopen it.

## STR
- Go to: `about:preferences#privacy -> View certificates...`
- Click "Add Exceptions..."
- Add new exceptions
- New server will be added to the display
- Repeat
- The box grows and pushes the buttons out of the picture
Bug: [User Journey] After refresh about welcome page becomes unfunctional
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-01-04 12:57:52+00:00
Resolved: 2024-01-19 17:56:45+00:00

**Found in**
* Firefox 122.0b5

**Affected versions**
* Firefox 122.0b5
* Firefox 121.0
* Firefox 120.0

**Affected platforms**
* Windows 10, Ubuntu 22, macOS 12

**Preconditions**
* Firefox IS NOT set as the default browser.

**Steps to reproduce**
1. Launch Firefox with new profile.
2. Have the first screen of the "about:welcome" page displayed.
3. Observe the elements displayed on the page, checkboxes are functional (can be checked/unchecked).
4. Click on "Skip this step" until you reach the Start browsing page.
5. Refresh the about:welcome page.

**Expected result**
* The checkboxes from the first slide are functional and clicking on "Skip this step" button the next slide appears.

**Actual result**
* The checkboxes from the first slide are not functional and clicking on "Skip this step" button appears an empty slide.

**Regression range**
* I will come back with regression range ASAP. 

**Additional notes**
* Latest Firefox Nightly not affected.
* See this issue in the attached screenshot.
Bug: Sorting on recent tabs after search is confusing
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-01-04 14:06:09+00:00
Resolved: 2024-04-25 14:18:07+00:00

I would've expected things to be shown in most recently used order, but as shown in the screenshot that is not the case. I haven't been able to figure out what order the list is in. It doesn't seem to match tab order either.
Bug: ASRouter tests under browser/components/asrouter are not being run in CI
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-01-04 14:13:19+00:00
Resolved: 2024-01-11 14:33:54+00:00

Bug 1866802 moved a chunk of ASRouter out to browser/components/asrouter, and that included a number of tests. Unfortunately, those tests are fairly special, and use a `try-runner.js` script to run them in CI. I forgot to do that step when I did the move, so we haven't been running the ASRouter tests under browser/components/asrouter since the move.

This bug is to fix that.
Bug: [Ubuntu] Checkmark from Menu Bar checkbox is not entirely visible with High Contrast Theme.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-01-04 14:52:33+00:00
Resolved: 2024-01-22 16:46:04+00:00

**Found in**
* Firefox 122.0b5

**Affected versions**
* Firefox 122.0b5
* Firefox 123.0a1

**Tested platforms**
* Affected platforms: Ubuntu 22
* Unaffected platforms: Windows 10, macOS 12

**Preconditions**
*  Have High Contrast Theme set from OS system settings.

**Steps to reproduce**
1. Launch Firefox.
2. Go to Menu - More tools - Customize toolbars
3. Click on Menu Bar checkbox
4. Observe the checkmark from Menu Bar checkbox

**Expected result**
* The checkmark is entirely visible with High Contrast Theme.

**Actual result**
* The checkmark is not entirely visible with High Contrast Theme.

**Regression range**
* I will come back with regression range ASAP.

**Additional notes**
* Right click on toolbar and observe the Menu Bar checkmark, it is not visible either, see also View/Zoom/Zoom Text Only checkmark.
Bug: scrollbutton-down and scrollbutton-up toolbarbuttons are missing accessible names
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-01-04 16:19:51+00:00
Resolved: 2024-08-23 11:42:01+00:00

`scrollbutton-down` and `scrollbutton-up` toolbarbuttons are not labeled and it would prevent users of assistive technology from knowing their purpose and, for instance, speech-to-text software users won't be able to activate them by calling their name and screen reader users won't know what these controls are expected to do, when passing through them in a browse mode or in a list of buttons/controls.
Bug: Cursor icon changed from hand with pointy finger to hand
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-01-05 10:48:53+00:00
Resolved: 2024-01-05 11:48:04+00:00

Steps to reproduce:

Using Debian sid/unstable with Nightly 123.0a1, 20240104213501, hover over a link.


Actual results:

The cursor icon changed to a “normal hand” with all fingers extended(?).


Expected results:

It should be the hand with only the pointy finger extended.
Bug: [MacOS] VoiceOver does not read the webcompat reporter's description automatically
Status: NEW
Priority: --
Created: 2024-01-05 12:30:17+00:00
Resolved: 2024-01-05 15:51:13+00:00

**Found in**
* Beta v122.0b2

**Affected versions**
* Nightly v123.0a1
* Beta v122.0b1, v122.0b5

**Tested platforms**
* Affected platforms: MacOS + VoiceOver
* Unaffected platforms: -

**Steps to reproduce**
1. Launch JAWS, then Firefox
2. Make sure new webcopmpat feature is enabled:
ui.new-webcompat-reporter.enabled  = true
3. Load any webpage
4. Go to Hamburger Menu / Report broken site
4. Observe how VoiceOver reads the new webcompat reporter dialog.

**Expected result**
* The description is being read automatically.

**Actual result**
* Only the URL textbox is being read.

**Regression range**
* not a regression, but an implementation flaw.

**Additional information**
* The description can, however, be read by manually navigating inside the dialog with VO commands.
* This bug was logged as a follow-up after [this comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1866251#c13).
Bug: [Experiment] The URL of the "VPN Moments" page from the "Treatment A" branch is wrongly set to "https://www.mozilla.org/en-GB/firefox/welcome/17a/" instead of "https://www.mozilla.org/en/firefox/welcome/17a/"
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-01-05 12:52:24+00:00
Resolved: 2024-01-08 12:54:23+00:00

**[Affected versions]:**
- Firefox Release 121.0 - Build ID: 20231211174248

**[Affected Platforms]:**
- Windows 11 x64
- macOS 14.1
- Ubuntu 22.04 x64

**[Prerequisites]:**
- Have a Firefox profile with the following prefs in the "about:config" page:
  - `nimbus.debug` pref set to `true`
  
**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Navigate to "about:studies?optin_slug=moments-page-january-en&optin_branch=treatment-a&optin_collection=nimbus-preview" and restart the browser.
3. Restart the browser again and observe the URL of the "VPN Moments" page.

**[Expected result]:**
- The "https://www.mozilla.org/en/firefox/welcome/17a/" is displayed.
    
**[Actual result]:**
- The "https://www.mozilla.org/en-GB/firefox/welcome/17a/" URL is displayed instead.

**[Additional Notes]:**
- Attached a screen recording of the issue.
Bug: [Ubuntu] Success message is not announced by ORCA when a report is successfully submitted via new Report Broken Site in 1/3 entry points
Status: NEW
Priority: --
Created: 2024-01-05 13:07:13+00:00
Resolved: 2024-02-06 21:29:23+00:00

**Found in**
* Beta v122.0b2

**Affected versions**
* Nightly v123.0a1
* Beta v122.0b1, v122.0b5

**Preconditions**
* Make sure: ui.new-webcompat-reporter.enabled = true

**Steps to reproduce**
1. Ensure ORCA is running
2. From any site, open a new `Report Broken Site` tool (from the MenuBar/Help/Report Broken Site!)
3. Fill in the form with test data
4. Navigate to and press `Send` button with keyboard navigation
5. Observe the announcement of the screen reader

**Expected result**
* Screen reader announces that the report is successfully sent, the screen reader announces the success message, at minimum the text that is visually a title of the dialog: `Success: Your report has been sent` 

**Actual result**
* Screen reader only announces the `Okay, button` (where the focus is placed), all of the above content that includes essential status data of the report is ignored.

**Regression range**
* Not a regr5ession but an implementation flaw.

**Additional notes**
* This issue only occurs if the Webcompat Reporter Tool is opened from the MenuBar/Help/Report Broken Site and not if opened from the HamburgerMenu or ProtectionPanel.
Bug: Pdf input elements flickers at zoom in or out
Status: NEW
Priority: --
Created: 2024-01-05 14:31:03+00:00
Resolved: 2024-06-20 10:41:18+00:00

**Found in**
* Firefox 122.0b5

**Affected versions**
* Firefox 121.0
* Firefox 122.0b5
* Firefox 123.0a1

**Tested platforms**
* Affected platforms: 
Ubuntu 22, macOS 13, Windows 10

**Steps to reproduce**
1. Launch Firefox and access the pdf: https://pdf.ninja/interactiveform_enabled.pdf
2. Zoom in and out the page

**Expected result**
Zoom action works as expected, there are no unexpected issues with the form.

**Actual result**
All input elements from the pdf(text fields, radio buttons or checkboxes) flickers

**Regression range**
I will come back with regression range ASAP.

**Additional notes**
I am able to reproduce this only on the pdf mentioned at step 1. Could not reproduce on other pdfs, like: http://foersom.com/net/HowTo/data/OoPdfFormExample.pdf
Bug: In Recent Browsing, entering and clearing a search term wipes out tabs from other devices
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-01-05 14:38:44+00:00
Resolved: 2024-01-18 09:33:14+00:00

Adding this as a clone of bug 1869895 as it appears to be a similar issue and introduced by the same regression (bug 1857634).

See attached .gif for a recording of the issue

**Steps to Reproduce**
1. In `about:config`, set `browser.firefox-view.search.enabled` to `true`.
2. Open Firefox View.
3. If necessary, sign into Mozilla accounts in order to populate tabs from other devices.
4. In the search box, enter a search term that contains some substring that will eventually match tabs in both device's tab lists when backspaced (Ex: in the attached gif, "te" was a match in both device's tab lists, so backspacing out "testing" worked).
5. Clear out the search box slowly using backspace rather than the clear/"X" button
6. Repeat steps 4 and 5 if necessary until you see the second device's tab list not reappear when it should, but you should see it right away if you backspace slowly until it reaches the point where the search term matches tabs in multiple tab lists.

**Expected Result**
The original tab lists are restored.

**Actual Result**
The tab lists are blanked out.

This is because we need to check if ANY tab lists have `updatesPaused` when they shouldn't rather than just checking the first one [here](https://searchfox.org/mozilla-central/source/browser/components/firefoxview/viewpage.mjs#230).
Bug: PDF Viewer: text with a background is invisible
Status: NEW
Priority: P3
Created: 2024-01-06 17:43:21+00:00
Resolved: 2024-03-04 21:55:57+00:00

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

Steps to reproduce:

Open the attached PDF file and display it in Firefox. Note: this is the out.pdf file from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731164#5


Actual results:

The text with the orange background is not visible (but it can be copied).


Expected results:

This text should be visible, just like with the current poppler-based PDF viewers. Note that old poppler-based PDF viewers had the same issue as Firefox, but it appears that poppler has been fixed (more details in the Debian bug report).
Bug: After editing the URLbar (Address Bar) it doesn't change on a change of webpage
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-01-06 19:15:43+00:00
Resolved: 2024-01-29 16:35:45+00:00

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

Steps to reproduce:

Using Firefox with no preexisting prefs.js or user.js files (that is, with all default prefs), go to a webpage.
Edit the text of, or paste into, the URLbar.
Go to a new webpage by clicking a link on the current webpage (that is, without pressing return to use the edited URL.)



Actual results:

The text in the URLbar stays the same.  That is, it doesn't show the URL of the newly current page, but the text that was edited before the webpage change.


Expected results:

The URLbar should show the URL of the current webpage on a webpage change, or, if the current behavior is deliberate, have some GUI indication that it isn't the URL of the current webpage.
This bug doesn't happen in Seamonkey.  The URL changes on a webpage change.
Bug: [Experiment] The "Recommend Add-ons - Staff pick" feature callout is not triggered
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-01-08 12:36:01+00:00
Resolved: 2024-01-19 18:33:22+00:00

**[Affected versions]:**
- Firefox Release 121.0 (Build ID: 20231211174248)
- Firefox Beta 122.0b6 (Build ID: 20240105091609)
- Firefox Nightly 123.0a1 (Build ID:20240107090723)

**[Affected Platforms]:**
- macOS 13.1
- Windows 10
- Linux Min 21.0

**[Prerequisites]:**
- Have a Firefox profile with the following prefs in the "about:config" page:
 - nimbus.debug set to true

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Navigate to the following link to force enroll in the treatment-a of the experiment: [link](about:studies?optin_slug=recommend-add-ons-staff-pick&optin_branch=treatment-a&optin_collection=nimbus-preview).
4. Open a new tab.
5. Observe the behavior.

**[Expected result]:**
- The "Recommend Add-ons - Staff pick" feature callout is triggered in the top right part.

**[Actual result]:**
- The "Recommend Add-ons - Staff pick" feature callout is NOT triggered.

**[Notes]:**
- The issue is reproducible using all the treatment branches.
- The issue is reproducible also with natural enrollment. 
- The feature callout is not triggered, because the "trigger" is missing from all the message configurations of the treatment branches. It seems that only the Control branch has the trigger set.
- I have cloned the experiment in the [Stage environment](https://stage.experimenter.nonprod.dataops.mozgcp.net/nimbus/cmunteanqa-2241-recommend-addons-staff-pick/summary), added the "trigger": { "id": "defaultBrowserCheck" } from the control branch, and the feature callout is successfully triggered.
Bug: Install Firefox 121.0 via gpo fails
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-01-08 13:53:28+00:00
Resolved: 2024-07-11 18:39:34+00:00

Steps to reproduce:

I downloaded the msi-package as usually from mozilla and added it to a gpo (this works since I created it for FireFox 108.0) to install in my domain.


Actual results:

The gpo-editor from Server 2016 gives me an error-message, that the current package could not be added at this time.
I attached the error-message (It's in german language).