av9ash/GitBugs huggingface dataset:
Bug: [Experiment] Users who enroll in the “Review Checker 119 new profiles” experiment are also enrolled in the “Fox Guide Reader Mode - Early Day User” experiment
Status: RESOLVED
Priority: P1
Resolution: WONTFIX
Created: 2023-10-06 13:22:41+00:00
Resolved: 2023-10-23 19:56:06+00:00

**[Notes]:**
- This scenario is due to the fact that the “Fox Guide Reader Mode - Early Day User” experiment has the “Sticky Enrollment” variable set to “true”. The “Fox Guide Reader Mode - Early Day User” experiment matches the targeting expression first and enrolls the user in the experiment.
Once the “Review Checker 119 new profiles” experiment also matches the expression targeting, the “Fox Guide Reader Mode - Early Day User” cannot invalidate the “Exclusion” targeting because of the “sticky” filter that was set.

**[Affected versions]:**
- Firefox Beta 119.0b5 - Build ID: 20231004091611

**[Affected Platforms]:**
- Windows 10x64
- macOS 13.1
- Ubuntu 22.04 x64

**[Prerequisites]:**
 - Have a new Firefox profile created and opened.
 - Have this “[user.js](https://drive.google.com/file/d/1BMUBtfCUsMPlGqwBo5lSai_OySx-YtGo/view?usp=sharing)” file saved on your computer.

**[Steps to reproduce]:**
1. Navigate to the “about:support” page and paste the “user.js” file into the User Profile.
2. Restart the browser (Ctrl/Cmd + Shift + J and Ctrl/Cmd + Option + R).
3. Navigate to the “about:studies” page.
4. Observe the displayed experiments in the “Active Studies” section.

**[Expected result]:**
 - The “Review Checker 119 new profiles” experiment is displayed in the “Active Studies” section and there is no “Fox Guide” experiment active.

**[Actual result]:**
- The “Review Checker 119 new profiles” and the “Fox Guide Reader Mode - Early Day User” are both displayed as “Active” in the “about:studies” page.

**[Additional Notes]:**
- This issue is also reproducible on the [“Review Checker 119 existing user profiles](https://experimenter.services.mozilla.com/nimbus/review-checker-119-existing-user-profiles/summary)” with the [“Fox Guide Reader Mode - Existing User”](https://experimenter.services.mozilla.com/nimbus/fox-guide-reader-mode-existing-user/summary) experiment.
- Attaching a screen recording of the issue [here](https://drive.google.com/file/d/1zQ3dht47gXarMTyhrKClvRcArK_Aw3Hu/view?usp=sharing).
Bug: Chrome and Firefox parse certificate subject name information in digital certificates differently
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-10-06 17:22:29+00:00
Resolved: 2023-10-26 14:01:57+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 Edg/113.0.1774.35

Steps to reproduce:

1.Use Python to create a local server (e.g. using Flask) and specify a mutated certificate and private key. Access the Flask provided url in Chrome.
2.In Firefox, visit the url about:certificate?cert=(processed pem data) containing the certificate information.
3.In your own developers'way, let the browser parse mutated certificate files, then observe the results.


Actual results:

Description: We tested with a mutated digital certificate as a test case. We have discovered differences in the parsing results of the certificate  subject name for mutated digital certificates between Google Chrome and Mozilla Firefox browsers.
OS: Windows 10 22H2 19045.2604
My expectations: Confirm whether this is a security bug or a UI bug.


Expected results:

I don't know which of these two different certificate subject name is correct or displaying non-standard characters in the subject name on the certificate itself is an error. So I need you to confirm whether this difference is a bug or not.
Bug: Chrome and Firefox parse certificate CRL and Cert Policies in digital certificates differently
Status: UNCONFIRMED
Priority: --
Created: 2023-10-06 18:12:59+00:00
Resolved: 2024-02-06 11:13:53+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 Edg/113.0.1774.35

Steps to reproduce:

1.Use Python to create a local server (e.g. using Flask) and specify a mutated certificate and private key. Access the Flask provided url in Chrome.
2.In Firefox, visit the url about:certificate?cert=(processed pem data) containing the certificate information.
3.In your own developers'way, let the browser parse mutated certificate files, then observe the results.


Actual results:

Description: We tested with a mutated digital certificate as a test case. We have discovered differences in the parsing results of the certificate CRL and Cert Policies for mutated digital certificates between Google Chrome and Mozilla Firefox browsers.
Mutation Strategy: Exchange a distribution point URL node in CRL and a domain name node in Cert Policies through TLV structure.
OS: Windows 10 22H2 19045.2604
My expectations: Confirm whether this is a security bug or a UI bug
Additional Comments:The public key of the certificate is generated by myself using my own private key and has been replaced.


Expected results:

I don't know which of these two different certificate CRL and Cert Policies is correct. So I need you to confirm whether this difference is a bug or not
Bug: Chrome and Firefox parse certificate Cert Policies and Issuer in digital certificates differently
Status: UNCONFIRMED
Priority: --
Created: 2023-10-06 18:33:04+00:00
Resolved: 2024-02-06 11:14:56+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 Edg/113.0.1774.35

Steps to reproduce:

1.Use Python to create a local server (e.g. using Flask) and specify a mutated certificate and private key. Access the Flask provided url in Chrome.
2.In Firefox, visit the url about:certificate?cert=(processed pem data) containing the certificate information.
3.In your own developers'way, let the browser parse mutated certificate files, then observe the results.


Actual results:

Description: We tested with a mutated digital certificate as a test case. We have discovered differences in the parsing results of the certificate Cert Policies and Issuer for mutated digital certificates between Google Chrome and Mozilla Firefox browsers.
Mutation strategy: The OID of CPS has been exchanged with the OID of ccountry.
Additional Comments:The public key of the certificate is generated by myself using my own private key and has been replaced.
OS: Windows 10 22H2 19045.2604
My expectations: Confirm whether this is a security bug or a UI bug.


Expected results:

I don't know which of these two different certificate Cert Policies and Issuer is correct. So I need you to confirm whether this difference is a bug or not
Bug: The interval timer in FxviewTabList should be extracted so the parent component manages if/when to update
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-10-06 21:28:43+00:00
Resolved: 2024-01-05 14:38:44+00:00

We currently have a setInterval timer constantly refreshing FxViewTabList instances based on a `browser.tabs.firefox-view.updateTimeMs` pref. This is to update "last accessed" column so it says e.g. 5mins ago or whatever. But the list component itself doesnt really have the context it needs to know when to start and stop that timer - if the card its in get collapsed, it should stop. Or maybe the whole list is periodically refreshed anyhow so the constant tick isn't necessary. 
If we extract that stuff to the parent component which creates and owns the list, we should be able orchestrate all that better.  It might be a mixin for components that need to update on a regular timer, or context-specific for the different data types and sections on FxView.
Bug: Perma [tier 2] browser/components/migration/tests/browser/browser_do_migration.js | We expect at least one assertion to fail because this test file is marked as fail-if in the manifest. -
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2023-10-07 00:42:46+00:00
Resolved: 2023-10-09 19:49:56+00:00

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

---
```
[task 2023-10-07T00:00:14.702Z] 00:00:14     INFO - TEST-PASS | browser/components/migration/tests/browser/browser_do_migration.js | Resource progress group for BOOKMARKS_FROM_FILE should be hidden. - true == true - 
[task 2023-10-07T00:00:14.703Z] 00:00:14     INFO - Leaving test bound test_invalid_resource_type
[task 2023-10-07T00:00:14.703Z] 00:00:14     INFO - Buffered messages finished
[task 2023-10-07T00:00:14.704Z] 00:00:14     INFO - TEST-UNEXPECTED-PASS | browser/components/migration/tests/browser/browser_do_migration.js | We expect at least one assertion to fail because this test file is marked as fail-if in the manifest. - 
[task 2023-10-07T00:00:14.705Z] 00:00:14     INFO - TEST-INFO | expected FAIL
[task 2023-10-07T00:00:14.705Z] 00:00:14     INFO - GECKO(11532) | MEMORY STAT | vsize 11479MB | residentFast 501MB | heapAllocated 295MB
[task 2023-10-07T00:00:14.706Z] 00:00:14     INFO - TEST-OK | browser/components/migration/tests/browser/browser_do_migration.js | took 2440ms
```
Bug: Unremovable Firefox suggest result (history)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-10-07 05:28:46+00:00
Resolved: 2023-10-09 15:10:53+00:00

Normally, you can delete a "Firefox Suggest" result (from browser history) by pressing Shift+Del, or clicking the "..." and selecting "Remove from History".  However, I have somehow experienced two instances where a suggestion became undeletable, and could not be removed from suggestions.

The first time this happened, I directly edited "places.sqlite" and removed the entry manually, which was effective at removing it from suggestions.

Now it's happened again, and I'd like to know how I would collect error information on this?  Obviously some piece of code is attempting to delete the suggestion, is failing to delete it, and is not showing any error message or anything.

---

What I did:

Type into address bar
Navigate to a suggestion using up and down arrow keys
Press "Shift + Del" or press the (...) button, then select "Remove from History"

What's supposed to happen:
Suggestion gets deleted

What happened:
Suggestion stayed there
Bug: Selected disabled option in <select> has wrong text color on macOS
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-10-07 06:26:30+00:00
Resolved: 2023-10-16 09:00:40+00:00

Open the following test case in Nightly:
```
data:text/html,<html><body><select><option disabled selected="true">My color is incorrect.</option><option disabled>My color is correct.</option></select></body></html>
```

After bug 1851689, the selected disabled option has the text color of a non-disabled hovered option. This is incorrect and difficult to read. Attached is an example of how this appears on macOS.

Both options should have the same text color.

The specific patch that regressed this per mozregression:
```
Bug 1851689 - Move some shared rules to menu-shared.css. r=dao,desktop-theme-reviewers

Linux and windows could get even more sharing. I suspect a bunch of the
macOS-specific CSS can go away now that we use native menus for the
menubar and context menus, but I don't have the time to test macOS
extensively right now so leaving it there for the moment...

Depends on D188801

Differential Revision: https://phabricator.services.mozilla.com/D188802
```
Bug: Doesn't fully translate the page from english to bangla
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-10-07 06:42:15+00:00
Resolved: 2023-10-09 16:30:04+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36

Steps to reproduce:

I clicked to change the page language from English to Bangla.


Actual results:

The page didn't translated from english to bangla. There was all of them english and a few was in bangla.


Expected results:

It should have happened that the page fully translate from one language to the other language upon clicking the language change option.
Bug: iframe's cookies and other storages  in firefox extension popup page are not working
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-10-07 07:08:30+00:00
Resolved: 2024-05-06 12:20:21+00:00

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

Steps to reproduce:

1.  create a  firefox extension's popup page
2.(optional) create an web  application that use cookie to login, which listen local's 8000 port; 
3. insert an iframe element into popup page and give it an src such as  http://localhost:8000 or other online page "https://www.ChallengeRunner.com/login/isiframe/1297/"
4. open extension's popup page. and login in ; 




Actual results:

you will found cookie is not auto append with XHR's header;
beside, firefox debugger can't inspect the iframe which in popup's page at all!


Expected results:

web app in iframe, cookies should auto append with XHR's header;
firefox debugger should  could inspect the iframe which in popup's page ;
attached files show some details
Bug: Keyboard shortcuts differ between Windows and Linux
Status: NEW
Priority: --
Created: 2023-10-07 08:35:49+00:00
Resolved: 2023-10-18 12:49:41+00:00

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

Steps to reproduce:

Shortcuts on windows and on linux are different, please make them identical.

1. ctrl+1 on windows; alt+1 on linux
2. ctrl+y on windows; ctrl+shift on linux
etc etc



Actual results:

shortcuts are different


Expected results:

shortcuts should be identical across different OSes
Bug: The accent color in the tab bar no longer works on Windows 10/11 when using the experimental key.
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-10-07 16:06:42+00:00
Resolved: 2023-12-13 17:23:01+00:00

Steps to reproduce:

I activated the `widget.windows.titlebar-accent.enabled` key in the about:config.


Actual results:

Activating the `widget.windows.titlebar-accent.enabled` key does not give the expected result.


Expected results:

The key `widget.windows.titlebar-accent.enabled` must enable the accent color according to its description.
Bug: copy event no longer emitted by PDF viewer
Status: ASSIGNED
Priority: P1
Created: 2023-10-08 20:35:39+00:00
Resolved: 2023-10-09 09:43:47+00:00

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

Steps to reproduce:

Added a `copy` event listener to the built-in PDF viewer, expecting it to get called when a copy event happened, as was the behavior in prior versions of Firefox.

To reproduce:
1. Open a PDF document in firefox: https://browse.arxiv.org/pdf/1908.06809v2.pdf
2. Open the Firefox console.
3. Execute the following statement: `document.addEventListener('copy', function(e){ console.debug("copy event", e) });`
4. Select some text in the PDF document, right-click the selection and click "Copy". Alternatively press CTRL-C instead of using the context menu.


Actual results:

Nothing


Expected results:

The text "copy event" with the details of the event should have been logged to the firefox console, at debug level.

Note: Normal web pages that do not use the Firefox PDF viewer, do properly emit the event on copy, so the issue seems to relate to some recent change in the PDF viewer implementation itself. A few versions back (prior to 115.esr3) the PDF viewer _did_ emit the copy event. Unfortunately I'm not sure exactly of the update this broke, so some bisecting would seem in order.
Bug: Errativ behavior of saved bookmarks
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-10-09 08:57:09+00:00
Resolved: 2024-02-19 09:06:53+00:00

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

Steps to reproduce:

In short: My bookmarks are being shuffled around randomly.

This is manifesting in several ways: 
- I have my bookmark bar always visible, sometimes the order is mixed up and bookmarks are in the wrong place. Never all at once, it's just one here and there.
- Some bookmarks will be relocated to other places.
- Some bookmarks will be collected in a weird folder with literal "[Folder Name]" (Ordnername, german, its localized) in its title.
- Some bookmarks are being duplicated.
- Some bookmarks seem to be deleted, too (?), but I'm not 100% certain about that.

This all started a few versions back after an upgrade. Sadly I forgot which one. It got gradually worse however. Maybe a corruption of the bookmarks database?

I know that this one will be hard to debug or find the root cause, but I think it's still needed to file the bug.
Bug: Either a promise or an async function, created in the window scope when adding a bookmark, stale forever
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-10-09 09:46:48+00:00
Resolved: 2023-11-21 08:04:27+00:00

Bug 1832222 was opening a new window, adding a bookmark and closing it. This creates a BookmarkState and registers various transactions with the PlacesTransactions module.

One of these transactions never resolves after closing the window, likely because of bug 1674505, though with various experiment on Try I couldn't identify which promise is hanging.

The bug actually happens at the [clearTransactionsHistory call in head.js](https://searchfox.org/mozilla-central/rev/7baa783763c946ff667c3faea292e91d3de1e459/browser/components/places/tests/browser/head.js#530,532) and it's surely due to the window scope where the work happens going away.

This may cause the TransactionsManager to hang indefinitely, as it manages a queue of promises. We have a timeout race on it, but it's a 5 minutes timeout so it won't help tests (also reducing that didn't seem to help here)
Bug: Get VPN promo is not being displayed in the More from Mozilla section in all the regions where the service is available
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-10-09 11:40:22+00:00
Resolved: 2023-11-01 10:46:47+00:00

**[Prerequisites]:**
- “browser.search.region” config is set to any of the following regions: "as,at,be,ch,es,fi,gg,ie,im,io,it,je,mp,nl,pr,se,uk,um,vg,vi".

**[Steps to reproduce]:**
1. Open the browser;
2. Navigate to “about:preferences#moreFromMozilla”;
3. Observe the behavior.

**[Expected result]:**
- Mozilla VPN should be recommended to users and be displayed in the More from Mozilla section since the regions from prerequisites all have Mozilla VPN available as a service.

**[Actual result]:**
- Mozilla VPN product promo is not displayed. Only other products such as Firefox Mobile and Firefox Relay are present.

**[Notes]:**
- Issue does not reproduce for the following regions: "us,ca,nz,sg,my,gb,de,fr" and Mozilla VPN is correctly being displayed in More from Mozilla. Due to this we believe that [this](https://searchfox.org/mozilla-central/rev/3d0b07f5a3c7b8d9955fb8e8acaaf582b1e33bb6/toolkit/modules/BrowserUtils.sys.mjs#505) list of regions is being used instead of the intended one, which should be [this](https://searchfox.org/mozilla-central/source/browser/app/profile/firefox.js#2040) one. As it can be seen, the full list of regions contains the ones that are currently functional, but it also contains the ones from prerequisites that are not working.
Bug: "Switch to tab" button doesn't match the dark theme colors
Status: NEW
Priority: --
Created: 2023-10-09 11:50:58+00:00
Resolved: 2023-10-09 12:41:21+00:00

**Found in**
* 120.0a1

**Affected versions**
* 120.0a1
* 119.0b6
* 118.0.1

**Affected platforms**
* Windows 10 x64

**Steps to reproduce**
1. Enable Dark mode in Windows
2. Enable System theme — auto in Firefox
3. Reach reddit.com
4. In another tab reach reddit.com again and observe the address bar

**Expected result**
* "Switch to tab" button should match the dark theme colors

**Actual result**
* "Switch to tab" button doesn't match the dark theme colors

**Regression**
* N/A.
Bug: bookmark sorting displayed incorrectly
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-10-09 14:07:39+00:00
Resolved: 2024-02-15 14:11:53+00:00

Steps to reproduce:

create 2 Separators, then drag Bookmarks between them


Actual results:

Firefox does not display the moved bookmarks corrrectly unless the Bookmarks Toolbar is updated by clicking another folder in the Bookmarks list


Expected results:

bookmarks should be displayed where they actually are located.  they are in the correct location, but not DISPLAYED correctly.
Bug: Preview state doesn't scroll with page
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-10-09 14:49:51+00:00
Resolved: 2023-10-27 10:53:02+00:00

STR: 
1. set `screenshots.browser.component.enabled` to true
2. open the new tab page or any scrolling page
3. open screenshots and scroll down

ER:
The preview state remains in the viewport

AR:
The preview state stays at the top of the page
Bug: The x, copy, and download buttons show when scrolling in the preview state
Status: RESOLVED
Priority: P1
Resolution: WORKSFORME
Created: 2023-10-09 14:51:06+00:00
Resolved: 2023-11-09 19:15:54+00:00

STR:
1. set screenshots.browser.component.enabled to true
2. open the new tab page or any scrolling page
3. open screenshots and scroll

ER:
The buttons will not show

AR:
The buttons show
Bug: Custom keyword search breaks when question mark (?) in search string
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-10-09 15:38:48+00:00
Resolved: 2024-01-17 15:42:37+00:00

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

Steps to reproduce:

I create a custom keyword search, in this case 

https://translate.google.com/?sl=en&tl=es&text=%s&op=translate

with the keyword 'eng' (for translating english to spanish).

This works great, like all other custom keyword searches, UNLESS there is a question mark in the query string contains a question mark, ie. when I want to translate a question. 





Actual results:

In that case (typing 'eng test?' in the search bar), it breaks and instead queries the default search engine with 'eng test?', so it ends up on this webpage (Ecosia in this case):

https://www.ecosia.org/search?q=eng%20test%3F&addon=firefox&addonversion=4.1.0&method=topbar


Expected results:

It should escape the question mark (or otherwise parse it correctly) and go to the correct URL: 

https://translate.google.com/?sl=en&tl=es&text=test?&op=translate


I have also tried parsing it with JavaScript like so:
javascript:void(window.open('https://translate.google.com/?sl=en&tl=es&text=' + encodeURIComponent('test?') + '&op=translate'))

This works if run from the console, but not from a custom search, where it would be

javascript:void(window.open('https://translate.google.com/?sl=en&tl=es&text=' + encodeURIComponent('%s') + '&op=translate'))
Bug: Title separator is missing from onboarding tab-to-search rows
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-10-09 16:53:37+00:00
Resolved: 2023-10-12 12:39:42+00:00

The title separator is missing from onboarding tab-to-search rows on Nightly. This is a regression from bug 1855639 and is similar to bug 1857108.
Bug: [win11] The installer no longer auto-pins in pre-22621.2361 builds of Windows.
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-10-09 19:52:35+00:00
Resolved: 2023-10-17 11:47:56+00:00

+++ This bug was initially created as a clone of Bug #1855340 +++

**Found in**
*  118.2 

**Affected versions**
* 118.2 and greater

**Tested platforms**
* Affected platforms: Windows 11x64
* Unaffected platforms: macOS 13, Ubuntu 22.1,  Windows 10x64

**Steps to reproduce**
1. Complete the Firefox installation using the default installation pathway on Windows builds before the September 2023 release (Specifically, a 22621 build but with a lower UBR number than 2361)

**Expected result** 
* Firefox is pinned without the user having to intervene

**Actual result**
* Firefox is not pinned

**Regression range**
* Not a regression

**Additional notes**

* Introduced by the fix for Bug #1855340