av9ash/GitBugs huggingface dataset:
Bug: UrlbarProviderExtension of dynamic type returns an unknown result type
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-02-21 09:00:33+00:00
Resolved: 2023-04-03 16:10:49+00:00

This is a follow-up for bug 1817202.
As commented in https://bugzilla.mozilla.org/show_bug.cgi?id=1817202#c2, as we had not supported UrlbarProviderExtension of dynamic type, the result type will be `unknown`.
To fix it, we will introduce `urlbar_extension` result type.
Bug: FeatureCallout in chrome doesn't fully clean up after itself
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-02-21 22:13:09+00:00
Resolved: 2023-03-15 09:29:39+00:00

In tabbrowser.js, under some circumstances we end the tour and clear the reference to the FeatureCallout instance, so it can be garbage collected. But the event listeners it created are not removed, as `endTour` doesn't call `_removePositionListeners`. That means they can pile up. I haven't done a complete assessment so there might be other things that need to be cleaned up too.

Also, the `pageEventManager` we instantiate on the window isn't cleaned up, but it isn't reused by the next FeatureCallout instance, either. When the tour ends, its listeners are all cleared, but it hangs around. And when the next FeatureCallout is instantiated, a new lazy getter is created and the `pageEventManager` property on the window is redefined. So, the previous one should be garbage collected, but there's really no need to recreate it. We could just reuse the previous one, if it exists.

I don't really like the system that's in place for dynamically lazy-loading PageEventManager, though. It basically does this thing where it defines a lazy getter on the FeatureCallout which loads PageEventManager, and that lazy getter also adds a reference to the PageEventManager on the window. The reason is that it allows the page listeners to reference `this.pageEventManager` (which _will_ load PageEventManager and instantiate one), while all the generic FeatureCallout code can reference `this.win.pageEventManager` instead (which will _not_ load anything). That way, if none of the messages have page event listeners, we don't need to load the manager. It only gets loaded when a message with a page event listener is loaded.

But when I wrote that, it was still just a page script with a bunch of separate functions. Now it's a class in a system module. It would be better to replace `this.pageEventManager` with `lazy.pageEventManager`, and replace `this.win.pageEventManager` with `this.pageEventManager`. That way we don't need to leak anything to the window.

And while we're adding a `lazy` object, it would be wise to move all the other lazy getters outside of the constructor and into the top level of the module. That is more consistent with the rest of the codebase and it also avoids redundantly defining module getters. The system module is singleton and persistent so we don't need to worry about the references working. I think the only reason we put the getters inside the ctor is because of the PageEventManager lazy-loading system I described before.
Bug: Full page screenshot takes a compound screenshot of the current and previous page
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-21 23:24:39+00:00
Resolved: 2023-02-23 19:48:47+00:00

**STRs**

1. Navigate to https://www.reddit.com/search?q=EPA%20Ohio&source=trending
2. Click the first post in the list - https://www.reddit.com/r/news/comments/1189khu/epa_demands_norfolk_southern_handle_all_cleanup/ (current first post for me)
3. Make a whole page screenshot of the page

**Expected result**
1. Screenshot of the current page up to 30k px in length is made. 

**Actual result**
1. A screenshot of the visible area of the current page is combined with a screenshot 
2. After the screenshot is downloaded, the browser then returns to the previous page (https://www.reddit.com/search?q=EPA%20Ohio&source=trending).
Bug: Intermittent toolkit/components/search/tests/xpcshell/searchconfigs/test_selector_db_out_of_date.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-02-22 06:23:03+00:00
Resolved: 2023-03-21 17:04:02+00:00

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

---
```
task 2023-02-22T06:09:53.632Z] 06:09:53     INFO -  TEST-START | widget/windows/tests/unit/test_windows_alert_service.js
[task 2023-02-22T06:09:53.632Z] 06:09:53     INFO -  TEST-SKIP | widget/windows/tests/unit/test_windows_alert_service.js | took 0ms
[task 2023-02-22T06:09:55.804Z] 06:09:55  WARNING -  PROCESS-CRASH | xpcshell.ini:toolkit/components/search/tests/xpcshell/searchconfigs/test_selector_db_out_of_date.js | application crashed [None]
[task 2023-02-22T06:09:55.804Z] 06:09:55     INFO -  Crash dump filename: C:\Users\task_167704516254394\AppData\Local\Temp\xpc-other-hhgmxd2h\312edd11-8eb7-4777-9888-f342ca94f127.dmp
[task 2023-02-22T06:09:55.804Z] 06:09:55     INFO -  stderr from minidump-stackwalk:
[task 2023-02-22T06:09:55.804Z] 06:09:55     INFO -  ERROR MissingHeader - Error reading dump: Missing minidump header (empty minidump?)
```
Bug: The CBH doorhanger's buttons cannot be targeted using keyboard navigation
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-22 14:00:21+00:00
Resolved: 2023-02-22 15:05:31+00:00

**[Affected versions]:**
- Firefox Beta 111.0b4 (Build ID 20230221190142)
- Firefox Nightly 112.0a1 (Build ID 20230221212648)

**[Affected platforms]:**
- Windows 10 x64
- macOS 12.5
- Ubuntu 22.04 x64

**[Prerequisites]:**
Have the following preferences set:
- cookiebanners.service.mode set to 1
- cookiebanners.service.mode.privateBrowsing set to 1
- cookiebanners.ui.desktop.cfrVariant set to 1
- cookiebanners.ui.desktop.enabled set to true
- cookiebanners.service.detectOnly set to true

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Navigate to a website with cookie banners (e.g. cnn.com).
3. Press the "Tab" key to cycle between the selectable elements.

**[Expected result]:**
- The CBH doorhanger's buttons are selected and can be pressed.

**[Actual result]:**
- The CBH doorhanger buttons cannot be selected.

**[Notes]:**
- The issue is also reproducible when pressing the F6 key to highlight the address before cycling between the elements with the "Tab" key.
- Attached a screen recording of the issue:
Bug: a download attribute: filename wrong displayed
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-22 14:03:16+00:00
Resolved: 2023-03-06 08:23:10+00:00

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

Steps to reproduce:

create a script who opens a csv file with the name "2023-02-22.csv" automatically: 

check the example at https://jsfiddle.net/yf2wu7kv/1/

function getMyCSV() {
  /* create csv file */
  const blb = new File(["a,b,c\n1,2,3"], '2023-02-22.csv', { type: 'text/csv' });

  /* open the download dialog */
  const a = document.createElement("a");
  a.style = "display: none";
  a.href = URL.createObjectURL(blb);
  a.download = '2023-02-22.csv';
  document.body.appendChild(a);
  a.click();
}

exec the function to open the download window (click the button in the jsfiddle).


Actual results:

the filename in the download window of Firefox is showed as "csv.2023-02-22" instead of  "2023-02-22.csv". when saving the file, in the windows save dialog, its correct again.

the error happens only when the filename consists only of numbers. when you add characters to the name, it's correct. 


Expected results:

the filename in the download window should be "2023-02-22.csv"
Bug: www.google.fr - Unexpected behaviour when scrolling bookmarks list
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-22 14:08:34+00:00
Resolved: 2023-02-22 16:43:56+00:00

From github: https://github.com/webcompat/web-bugs/issues/118603.

> <!-- @browser: Firefox 110.0 -->
> <!-- @ua_header: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0 -->
> <!-- @reported_with: unknown -->
> <!-- @public_url: https://github.com/webcompat/web-bugs/issues/118603 -->
> 
> **URL**: https://www.google.fr/
> 
> **Browser / Version**: Firefox 110.0
> **Operating System**: Windows 10
> **Tested Another Browser**: Yes Edge
> 
> **Problem type**: Something else
> **Description**: Scrolling bookmarks
> **Steps to Reproduce**:
> Since the Firefox version 110.0 (64-bit) update, the list of my current bookmarks systematically returns to the beginning (first) when I choose a favorite, whatever the web page I am on. Before, with the same settings, the list stopped where I left off, which was convenient. Now, each time I have to re-scroll the list to find the favorite that interests me. Is it possible to solve this problem, for example with "about:config" and if so, how?
> Thank you and sorry for my English: I am French
> 
> <details>
> <summary>Browser Configuration</summary>
> <ul>
>   <li>None</li>
> </ul>
> </details>
> 
> _From [webcompat.com](https://webcompat.com/) with ❤️_

Change performed by the [Move to Bugzilla add-on](https://addons.mozilla.org/en-US/firefox/addon/move-to-bugzilla/).
Bug: Popup-based injection of Mixed active content leading to MITM attacks.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-22 14:14:42+00:00
Resolved: 2024-05-30 18:05:47+00:00

In Firefox, loading mixed active content is blocked as a security measure, safeguarding its users from most sniffers and man-in-the-middle attacks

However, an attacker could exploit sites with allowed popup to open an `about:blank` page and request active insecure content, leading to MITM attacks. 

Steps to reproduce:
1. Load an HTTPS site, for example: https://www.google.com

2. Open the console on the same site and paste the following poc code to test:
```
var newWindow = window.open('about:blank');
setTimeout(function() {
    var iframe = newWindow.document.createElement('iframe');
    iframe.src = 'http://neverssl.com/';
    newWindow.document.body.appendChild(iframe);
  }, 1000);
```
The above code will successfully load insecure active content over the parent origin.

This vulnerability is similar to https://bugs.chromium.org/p/chromium/issues/detail?id=957002 . Both Safari and Chrome have fixed it, Mozilla is still vulnerable to this type of attacks.
Bug: Intermittent browser/base/content/test/general/browser_ctrlTab.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-02-22 14:16:08+00:00
Resolved: 2024-09-09 12:01:14+00:00

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

---
```
[task 2023-02-22T13:23:10.116Z] 13:23:10     INFO - TEST-PASS | browser/base/content/test/general/browser_ctrlTab.js | Releasing Ctrl closes the preview panel - 
[task 2023-02-22T13:23:10.116Z] 13:23:10     INFO - Buffered messages finished
[task 2023-02-22T13:23:10.116Z] 13:23:10     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_ctrlTab.js | With 5 visible tabs and tab 5 selected, Ctrl+Tab*5 goes 0 tabs back in most-recently-selected order - "Got +0, expected 1"
[task 2023-02-22T13:23:10.116Z] 13:23:10     INFO - Stack trace:
[task 2023-02-22T13:23:10.116Z] 13:23:10     INFO - chrome://mochikit/content/browser-test.js:test_is:1493
[task 2023-02-22T13:23:10.124Z] 13:23:10     INFO - chrome://mochitests/content/browser/browser/base/content/test/general/browser_ctrlTab.js:ctrlTabTest:437
[task 2023-02-22T13:23:10.124Z] 13:23:10     INFO - TEST-PASS | browser/base/content/test/general/browser_ctrlTab.js | Content document doesn't capture Keyup event during cycling tabs - 
```
Bug: The close button of tabs changes size on hover
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-22 15:42:53+00:00
Resolved: 2023-02-25 00:01:25+00:00

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

Steps to reproduce:

1. Select a tab so the close button is visible.
2. Hover over the tab.


Actual results:

The size of the close button changes when the pointer is over the tab.


Expected results:

This is a regression from Bug 1710910.
Bug: When the pointer is over the menubar, typing to a textfield triggers the accelerator shortcuts
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-02-22 15:57:51+00:00
Resolved: 2023-03-03 07:53:27+00:00

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

Steps to reproduce:

1. Make the menubar always visible.
2. Focus on a textfield in a page.
3. Move the pointer over the Help menu.
4. Press one of the accel shortcuts visible (eng: f, e, s, b, t, h).


Actual results:

Instead of inserting the key, the menu opens.


Expected results:

This is a regression from Bug 1805414.
Bug: Regression: Tab close button flickers/expands when moving mouse cursor over the tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-22 16:34:22+00:00
Resolved: 2023-02-22 16:36:06+00:00

Nightly 112.0a1 (2023-02-22) (64-Bit)
MacOS 12.6.3

STR:

1.) Open a new window
2.) Move the mouse cursor over the tab

Actual: Tab close button flickers/expands.

Expected: No flicker/expand of the close button.

A demo is attached.
Bug: The CBH Private Browsing site exceptions are not applied in the same session
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-22 16:36:56+00:00
Resolved: 2023-03-01 10:36:11+00:00

**[Affected versions]:**
- Firefox Beta 111.0b4 (Build ID 20230221190142)
- Firefox Nightly 112.0a1 (Build ID 20230221212648)

**[Affected platforms]:**
- Windows 10 x64
- macOS 12.5
- Ubuntu 22.04 x64

**[Prerequisites]:**
Have the following preferences set:
- cookiebanners.service.mode set to 1
- cookiebanners.service.mode.privateBrowsing set to 1
- cookiebanners.ui.desktop.cfrVariant set to 1
- cookiebanners.ui.desktop.enabled set to true
- cookiebanners.service.detectOnly set to false

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Open a new Private Browsing Window and navigate to a website with cookie banners (e.g. cnn.com).
3. Click the Shield icon from the awesomebar and click the "Cookie Banner Reduction" option.
4. Click the "Turn Off" option and observe the page.

**[Expected result]:**
- The page is refreshed and the page's cookie banner is displayed.

**[Actual result]:**
- The page is refreshed and the page's cookie banner does not reappear.

**[Notes]:**
- Attached a screen recording of the issue:
Bug: when on US Government MEDICARE site, and select "CHAT", no special characters are allowed. will not open
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-02-22 17:38:22+00:00
Resolved: 2023-04-10 08:01:01+00:00

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

Steps to reproduce:

signed onto the US MEDICARE government web site and selected CHAT and started to type in what I needed help with. The message included the "$" characters.


Actual results:

Window appears but nothing in it.  No indication that CHAT window was in contact with the MEDICARE support agent. I then exited FIREFOX to try VAVALDI. I signed onto MEDICARE from VAVALDI and repeated the same sign in and chat typing process  (typing in what I needed help on ) and got a site error message that I could not use "$" in my chat question.   This error message helped me understand why the MEDICARE web site may not been working when using FIREFOX. See the VAVALDI error message in the attached screen shot.


Expected results:

When using FIREFOX, I expected to see an error message that I could not use certain characters ("$") in my chat box.  I can correct the message to remove the unacceptable characters and resubmit the message.
Bug: Source find/search extremely slow
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-22 19:03:12+00:00
Resolved: 2023-03-20 06:47:28+00:00

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

Steps to reproduce:

Open source, search for any word, no options need to be selected.

Version 111.0b4 64bit, developer edition.


Actual results:

Search is processed per letter, completing processing before advancing.

If a word it typed, it will slowly process the complete results of each individual letter, vs waiting a period of time for typing to stop, then searching.

Browser will freeze until search word is completely typed out. Depending on what was typed, that can take a bit of time.


Expected results:

In previous versions the search would happen after typing was completed. In those cases the results were very quick.
Bug: PDF prints only fields modified after opening the document
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-22 19:29:38+00:00
Resolved: 2023-02-22 22:00:13+00:00

Attach (recommended) or Link to PDF file here:

Steps to reproduce the problem:
1. Download https://www.canada.ca/content/dam/ircc/migration/ircc/english/passport/forms/pdf/pptc153.pdf
2. Fill first name, last name
3. Ctrl+S to save it to disk
4. Close tab
5. Ctrl+O to open from disk
6. Notice that first and last name are still visible
7. Edit one field
8. Ctrl+P to print
9. Notice that only recently modified field is printed. All other fields, while still visible on screen, are not printed.

What is the expected behavior? (add screenshot)

I expect print to have all the fields I've filled

What went wrong? (add screenshot)

Print preview (and printed version) does not have any fields filled and saved before. Only fields modified after loading file are printed. All saved fields are preserved on screen after reload, just not printed.
Bug: Cookie Banner promo illustration vector has a weird stroke corner radius
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-22 20:12:09+00:00
Resolved: 2023-03-14 15:08:27+00:00

See attached screenshot. The stop sign's stroke is too fluffy. Need to re-export and see what went wrong. Maybe not use SVGO to compress it this time, or not use the default settings.
Bug: TPS - HTTP POST send empty body to /storage/tabs?batch=true&commit=true
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-22 20:46:25+00:00
Resolved: 2023-03-07 16:11:48+00:00

One of the Firefox iOS tests, test_sync_tabs_from_desktop, passed the last time on Jan 21, 2023. This set of tests uses TPS for synchronizing data between the browsers (desktop & mobile).

In particular, an HTTP POST to /tabs?batch=true&commit=true is supposed to contain a body according to the sync log:

1674321037934	Sync.Collection	DEBUG	POST success 200 https://stage.sync.nonprod.cloudops.mozgcp.net/1.5/6562162/storage/tabs?batch=true&commit=true
1674321037934	Sync.Collection	TRACE	POST body: {"modified":1674321037.89,"success":["KxsGIwX0dtLt"],"failed":{}}

After the date, the same HTTP POST call does not include a body:

1675789923800	Sync.Collection	DEBUG	POST fail 412 https://stage.sync.nonprod.cloudops.mozgcp.net/1.5/6562821/storage/tabs?batch=true&commit=true
1675789923800	Sync.Collection	TRACE	POST body: 
1675789923800	Sync.Collection	WARN	POST request to https://stage.sync.nonprod.cloudops.mozgcp.net/1.5/6562821/storage/tabs?batch=true&commit=true failed with status 412

The test in question is supposed to synchronize a tab from Firefox desktop to the server 
var tabs1 = [
    { uri: "http://example.com/",
      profile: "Fennec on iOS"
    }
];
See https://github.com/clarmso/firefox-ios/blob/main/SyncIntegrationTests/test_tabs_desktop.js#L14 for the js file used by TPS.

Here is the test result from the last time the test passed.
https://storage.googleapis.com/mobile-reports/public/firefox-ios-M1/result_385/SyncIntegrationTests/results/index.html

Here is a test result describing the failure.
https://storage.googleapis.com/mobile-reports/public/firefox-ios-M1/result_417/SyncIntegrationTests/results/index.html
Bug: --panel-description-color is currently using system color GrayText reserved for disabled items only
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-02-22 21:25:42+00:00
Resolved: 2023-06-02 15:24:16+00:00

`global-shared.css` currently sets `--panel-description-color` to `GrayText`. Accessibility recommends we reserve `GrayText` for disabled or placeholder items only.
Bug: RTAMO onboarding page design is cut at the bottom along with the “Not Now” button
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-23 07:39:21+00:00
Resolved: 2023-03-03 08:04:23+00:00

Affected versions:
- Nightly (112.0a1/20230222214030)
- Beta (111.0b4/20230221190142)

Description:
The RTAMO onboarding page design is cut at the bottom and along with it, the “Not Now” button. A small portion of the upper part of the button is still visible and can be clicked to expand the address bar i.e. functionality is not affected.

Steps to reproduce:
1. While using a VM with Windows, launch Edge or Chrome and access https://addons.mozilla.org 
2. On AMO, access the page of any add-on and click the “Download Firefox and get the extension” button
3. Once the installer is downloaded, run it to install Firefox (This will install the latest Firefox Release 110.0)
4. After installation Firefox Release will launch and the RTAMO onboarding page will be displayed, the “Not Now” button being fully visible and none of the page contents being cut.
5. Open the installation folder of Firefox Release, locate the “postSigningData” file and copy it to Desktop.
6. Download and install the latest Firefox Nightly 112.0a1 and Firefox Beta 111.0b4
7. Open the installation folders of Nightly and Beta and paste the previously copied “postSigningData” file inside the folders.
8. Launch both Nightly and Beta and access about:welcome on the browsers
9. The RTAMO onboarding page will be displayed on both browsers, but the page design will be cut at the bottom along with the “Not Now” button. The upper part of the button is still visible and can be clicked.

Actual:
RTAMO onboarding page design is cut at the bottom along with the “Not Now” button.

Expected:
The RTAMO onboarding page contents are fully displayed.
Bug: browser.urlbar.resultMenu.keyboardAccessible=false makes the result menu button unselectable by mouse
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-02-23 10:22:52+00:00
Resolved: 2023-02-24 08:54:30+00:00

As reported by :srose in bug 1813517 comment 15:
> Testing this in Nightly 112.0a1 (2023-02-22), with `browser.urlbar.resultMenu.keyboardAccessible` set to false the result menu buttons are indeed skipped when navigating using the tab key, but when clicking on the result menu buttons with the mouse cursor the menu isn't shown.
Bug: PlacesFeed module is doing expensive work during Places notifications
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-02-23 10:55:06+00:00
Resolved: 2024-02-12 21:48:51+00:00

I took a profile from the suggestion in bug 1533061
https://share.firefox.dev/3XWswU0

on notifications this is doing a "dispatch" that doesn't look like being an actual async dispatch https://searchfox.org/mozilla-central/source/browser/components/newtab/lib/PlacesFeed.jsm#64,160,178-193
That apparently accounts for a good 30% of the time.

Since this listener is pretty much always active, it is slowing down various bookmarks (and maybe history) operations, it should do the minimum necessary in the notification handler, and redispatch/batch any expensive work.