av9ash/GitBugs huggingface dataset:
Bug: Address Bar dropdown glitches if ‘Recent Searches’ feature is disabled/enabled
Status: NEW
Priority: P3
Created: 2023-10-13 13:44:20+00:00
Resolved: 2024-02-26 11:19:40+00:00

**Notes**
* Screen recording attached. 

**Found in**
* Nightly 120.0a1;

**Affected versions**
* Nightly 120.0a1;

**Tested platforms**
* Windows 10;
* Ubuntu 22;
* macOS 13; 


**Affected platforms**
* Windows 10;
* Ubuntu 22;
* macOS 13; 


**Unaffected platforms** 
* N/A; 

**Preconditions**
* `browser.urlbar.recentsearches.featureGate` set to `true` 
* `browser.urlbar.suggest.recentsearches` set to `true` 

**Steps to reproduce**
1. Launch Firefox with the profile from preconditions.
2. Focus the Address Bar and perform some searches using the default search engine.
3. Open a new tab and focus the Address Bar.
4. Navigate to `about:preferences#search` and uncheck the ‘Recent Searches’ preference.
5. Open a new tab and focus the Address Bar.

**Expected result**
* Address Bar dropdown is loaded, no glitches or artifacts present. 

**Actual result**
* There’s a split second glitch showing the ‘Recent Searches’ section in the Address Bar dropdown. 

**Regression range**
* Not a regression.
Bug: Downloaded Blob files are not persisted in Downloads
Status: NEW
Priority: P3
Created: 2023-10-13 14:05:04+00:00
Resolved: 2023-11-21 08:55:13+00:00

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

Steps to reproduce:

1. Download a file using JavaScript Blob (for example https://jsfiddle.net/KimNyholm/p48nt3h7/)
2. Open Downloads
3. See that file is listed there (datafile.json if you are using the link above) 
4. Close Firefox
5. Reopen Firefox


Actual results:

File is gone from history, all other downloaded from direct links are still there


Expected results:

File should be still present in history (see Chrome)
Bug: Same search terms across different engines are using the same moz_historyform
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-10-13 14:43:11+00:00
Resolved: 2023-10-18 14:35:21+00:00

**Notes**
* While investigating this issue, we figured that for the same search terms queries spread across different engines have the same moz_historyform id, which in turn doesn’t allow deleting and will trigger a not so recent search term pop-up while using a different engine than the one that last_used was updated on.
* To our assessment, this issue and its implications, although it is a S3 from the browser perspective, it can be considered S1/S2 from the feature perspective.

**Found in**
* Nightly 120.0a1;

**Affected versions**
* Nightly 120.0a1;

**Tested platforms**
* Windows 10;
* Ubuntu 22;
* macOS 13; 


**Preconditions**
* browser.urlbar.recentsearches.featureGate set to true 
* browser.urlbar.suggest.recentsearches set to true 

**Steps to reproduce**
1. Launch Firefox with the profile from preconditions.
2. Focus the Address Bar and perform some searches(1,2,3,4,5) using the default search engine(A).
3. Change the default search engine and perform the same search using the new default engine(B) (1,2,3,4,5).
4. Open a new tab and focus the Address Bar.
5. Open the result menu and click on the ‘Remove from history’ option for the (3) of the recent search terms- recent search (3) for engineB is deleted
6. Switch back to the original search engine(A) and focus the Address Bar

**Expected result**
* Recent Search (3) is still displayed for the engine A

**Actual result**
* Recent Search (3) is not displayed for the engine A.

**Regression range**
* Not a regression.
Bug: History is deleted from the ‘Recent Searches’ section but not the browser history
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-10-13 14:45:34+00:00
Resolved: 2023-10-16 14:16:42+00:00

**Found in**
* Nightly 120.0a1;

**Affected versions**
* Nightly 120.0a1;

**Tested platforms**
* Windows 10;
* Ubuntu 22;
* macOS 13; 


**Affected platforms**
* Windows 10;
* Ubuntu 22;
* macOS 13; 


**Unaffected platforms** 
* N/A; 

**Preconditions**
* browser.urlbar.recentsearches.featureGate set to true 
* browser.urlbar.suggest.recentsearches set to true 

**Steps to reproduce**
1. Launch Firefox with the profile from preconditions.
2. Focus the Address Bar and perform some searches using the default search engine.
3. Open a new tab and focus the Address Bar.
4. For a recent search/keyword open the result menu and click on the ‘Remove from history’ option.
6. Repeat steps 4-5 for a few recent searches/keywords. 
7. Open History(from Hamburger Menu/Ctrl+Shift+O).

**Expected result**
* Recent Searches are removed from both the Address Bar Recent History and Browser history.

**Actual result**
* Recent Searches are removed only from the Address Bar history; they are still present in history. 

**Regression range**
* Not a regression.

**Later Edit:**
* The Address bar original search history removal would not delete the search from browser history, although we also believe that was wrong, since user perspective doesn't necesarily differentiates betwen the search term history and the search term query string.
Bug: Punycode is shown in history
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-10-13 15:50:55+00:00
Resolved: 2024-01-26 13:51:48+00:00

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

Steps to reproduce:

Visit https://рнидс.срб
Click on address bar emptiness, then click again


Actual results:

Cyrillic symbols are replaced to punycode in history


Expected results:

Cyrillic symbols are shown as they are
Bug: applyMomentsPolicy has at least incorrect comments, may be sending wrong data
Status: ASSIGNED
Priority: P1
Created: 2023-10-13 20:12:16+00:00
Resolved: 2025-03-03 18:05:08+00:00

https://searchfox.org/mozilla-central/rev/81a006cd60c54ce074d7158fafc5a2923717860e/browser/components/newtab/lib/TelemetryFeed.jsm#694 sez:

```
   * Per Bug 1484035, Moments metrics comply with following policies:
   * 1). In release, it collects impression_id, and treats bucket_id as message_id
   * 2). In prerelease, it collects client_id and message_id
   * 3). In shield experiments conducted in release, it collects client_id and message_id
```

To implement 3, it appears to be using `this.isInCFRCohort` as proxy for whether something is in an experiment.  In fact, what it's really checking is whether it's in an experiment on the `cfr` feature id, which means that in experiments running on other feature ids, it will not collect clientId or `message_id` (but will collect `impression_id`).

My suspicion is that in today's messaging system, we really want any experiment to use this policy, not just ones in CFR.  

I'm not sure what the story with `bucket_id` is or the full history is here, that will need more code / bug / issue archeaology than i've got time for at the moment

At the very least we should fix the comments here and on `applyCFRPolicy`.

Bonus points (maybe a spin-off bug) for putting these policies in the Glean dictionary so that there is at least a chance that data scientists will be able to find them.  See https://docs.google.com/document/d/1paTna8m7NWnWl_gFG9ZqUQQ3Lw7r8BKomdI28QBRdm4/ for some of the consequences this has on the data we've got now.
Bug: Screenshots buttons container can sometimes draw really wide
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-10-13 22:01:40+00:00
Resolved: 2023-11-01 14:30:49+00:00

STR: 
1. set screenshots.browser.component.enabled to true
2. on any page, open screenshots
3. draw a box so the right side of the box is within 300 pixels of the left side of the window
4. resize the box so the right side is now more than 300 pixels from the left side of the window. moving to the right side of the window works well

ER:
The buttons container should be normal width

AR:
The buttons container is very wide
Bug: turbo.build, linear.app website causing jank and making browser slow
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-10-13 23:10:33+00:00
Resolved: 2024-01-05 14:50:47+00:00

When I am visiting https://turbo.build/ or https://linear.app it's making Firefox slow and behave unusual than other pages. I can smoothly access https://turbo.build/pack or https://turbo.build/repo.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/119.0
Macbook M1 pro 16 GB running Sonoma 14.0
Bug: Run language detection before offering a translation (dxomark.com website detected as being French)
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-10-14 01:43:31+00:00
Resolved: 2025-03-03 19:59:07+00:00

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

Steps to reproduce:

Firefox needlessly offers to translate it from French to English which doesn't make any sense.

I'm using Firefox 118.0.2 (the official build) under Linux.
Bug: Revise change of AddressBar or reintroduction of browser.urlbar.clickSelectsAll and possible UI preference
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-10-14 12:20:21+00:00
Resolved: 2023-10-15 08:06:58+00:00

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

The full description copied from the original bug is below. I'll start with my reason to clone this bug:

- This behavior is the exact opposite of how all HTML input fields work including those of the most popular web searchers and every single search input field I have come across on the web. This fact makes it counterintuitive a disruptive to the user experience.

- The reason given for not fixing this issue is that some security features depend on this behavior. Is this desirable? Should security features depend on something like this? Isn't the actual problem the way these security features are implemented?

-Could a Firefox developer at least provide some advice how to create a workaround for this issue?

Original bug description follows:

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

Steps to reproduce:

More than 4 years ago firefox copied Google's changes on chrome that cause the entire text of the Address Bar to be selected when the user clicks anywhere on it, going against usability recommendations and user expectations of every single other text input element in all 5 major OSes. This change clearly benefits Google business model of trying to force the browser address bar to become a place for textual searches that can generate traffic to their search product.

Several users complained, as this is unexpected and non-standard (bug 1643973, bug 1621570, many other bugs not counting the external forums which would be too many to list). All bugs were closed by :mak with the very valid reasoning that keeping the old behaviour, or even a setting to restore it, would cause too much problems and overhead while experimenting with new Address Bar features. Ironically, i could only find places where the *new* behaviour caused bugs and unexpected problems with other features (bug 1199577, bug 1528614 etc). A ecosystem of work-around is showing up by now (https://bugzilla.mozilla.org/show_bug.cgi?id=1643973#c12)

This bug is a request for :mak and others to revise if more than 3 years have been enough to test all the features and prototypes the old, OS-consistent behaviour was impacting. And if we are done with those experiments, to either restore the old behaviour and stop copying Google Chrome, or reintroduce the setting (ideally as 1st class setting in the user-visible UX)
Bug: EZPass site doesn't work
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-10-14 12:51:17+00:00
Resolved: 2023-10-17 19:03:40+00:00

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

Steps to reproduce:

Go to this website https://myaccount.ezpassva.com/

doesn't work in firefox, works in anything else


Actual results:

The request is blocked


Expected results:

works
Bug: Calling requestStorageAccess() still creates multiple SharedWorkers.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-10-14 18:13:55+00:00
Resolved: 2023-10-17 09:30:46+00:00

To reproduce:
1. Visit https://cors-communication-a.glitch.me/ in one tab
2. Visit https://cors-communication-b.glitch.me/ in another
3. Click 'request storage access' in both tabs
4. Click 'initialize worker' in both tabs
5. Click 'send message' in one of the tabs

Expected: The message arrives in the other tab.
Actual: The message only arrives in the tab from which it was sent.
Bug: Multi Account container address bar button is too dark with Firefox dark theme
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-10-15 02:55:30+00:00
Resolved: 2023-10-17 13:14:12+00:00

Steps:

1. Install Multi Account Containers extension from Mozilla
2. Switch Firefox to dark theme
3. See that the bookmark button is too dark (see image)

Previously it was white I think
Bug: download pdf and open it
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-10-15 09:25:27+00:00
Resolved: 2023-10-18 13:26:28+00:00

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

Steps to reproduce:

Well, it's a user experience issue.

I download a pdf, I see it in the downloaded list file
I click on it, nothing appears, nothing nothing

I need to click on the icon folder ( right of the downloaded file icon ) where the downloaded file is.
So it opens the Windows Explorer, I double click on the pdf file and it opens in firefox



Expected results:

It would be fine that by clicking on the downloaded file pdf in the downloaded list, you have it opened directly in a new tab firefox
Bug: Intermittent browser/base/content/test/tabs/browser_link_in_tab_title_and_url_prefilled_new_window.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-10-16 11:40:33+00:00
Resolved: 2024-05-20 12:04:15+00:00

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

---
```
TEST-PASS | browser/base/content/test/tabs/browser_link_in_tab_title_and_url_prefilled_new_window.js | false == false - 
[task 2023-10-16T11:07:27.392Z] 11:07:27     INFO - Leaving test bound blank_page__by_script
[task 2023-10-16T11:07:27.392Z] 11:07:27     INFO - Buffered messages finished
[task 2023-10-16T11:07:27.395Z] 11:07:27     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/tabs/browser_link_in_tab_title_and_url_prefilled_new_window.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2023-10-16T11:07:27.396Z] 11:07:27     INFO - GECKO(5968) | MEMORY STAT | vsize 2104625MB | vsizeMaxContiguous 65141068MB | residentFast 430MB | heapAllocated 162MB
[task 2023-10-16T11:07:27.396Z] 11:07:27     INFO - TEST-OK | browser/base/content/test/tabs/browser_link_in_tab_title_and_url_prefilled_new_window.js | took 45729ms
```
Bug: [Experiments] Moments pages do not send Nimbus exposure telemetry (from "VPN moments page October Release" experiments)
Status: NEW
Priority: P3
Created: 2023-10-16 12:00:30+00:00
Resolved: 2023-10-23 17:21:04+00:00

**[Affected versions]:**
- Firefox Release 115.0.1 - Build ID: 20230706202047
- Firefox Release 116.0 - Build ID: 20230727152340
- Firefox Release 117.0.1 - Build ID: 20230912013654
- Firefox Release 118.0.2 - Build ID: 20231009140911
- Firefox Beta 119.0b9 - Build ID: 20231013091412
- Firefox Nightly 120.0a1 - Build ID: 20231015213401

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

**[Prerequisites]:**
- Have the following [User.js](https://drive.google.com/file/d/16Z8n2uE9AAXvCsYWredgABQIvVCx2BvV/view?usp=drive_link) saved to your PC.
- Have a Firefox profile younger than 28 days.


**[Steps to reproduce]:**
1. Navigate to the profile folder from the prerequisites and paste the "user.js" file.
2. Open the browser using the profile from prerequisites.
3. Navigate the the "about:telemetry#events-tab" page and observe the displayed events.
4. Restart the browser.
5. Navigate the the "about:telemetry#events-tab" page and observe the displayed events.

**[Expected result]:**
- Step 3 & 5: An "expose" telemetry ping related to the "VPN moments page October Release" experiments is displayed.
    
**[Actual result]:**
- Step 3 & 5: There is no "expose" ping displayed.

**[Additional Notes]:**
- The issue is reproducible on both the "VPN moments page October Release" experiments.
- According to the [Feature Manifest](https://searchfox.org/mozilla-central/source/toolkit/components/nimbus/FeatureManifest.yaml#879) an "expose" event should be generated for the "moments-page" feature config.
- Attached a screen recording of the issue.
Bug: Addresses and credit cards(Form autofill) not imported on snap build from Chromium
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-10-16 12:22:55+00:00
Resolved: 2023-10-17 08:52:37+00:00

[Found In]:
Nightly 120.0a1

[Affected versions]:

Nightly 120.0a1

[Affected platforms]:

Ubuntu 22

[Unaffected platforms]:
Ubuntu 20
macOS 12 ARM
Win10/Win11

[Preconditions]:
Install snap build.
The migration wizard is enabled by default with pref browser.migrate.chrome.get_permissions.enabled to true
browser.search.region to US
Have Chromium installed with bookmarks and history, saved addresses and credit cards


[Steps to reproduce]:

1. Open Firefox and go to about:preferences
2. Press the Import Data button
3. Press the continue button and follow the instructions from the wizard.
4. Import all available files from the location
5. Confirm the import and check it the saved addresses and credit cards are added to Firefox.


[Expected result]:

The saved addresses and credit cards should be added to Firefox.

[Actual result]:

The saved addresses and credit cards are not added to Firefox. 

[Regression range]:

New feature implementation for Ubuntu 22, Snap builds

[Additional Notes]:
I noticed that Form autofill option is not displayed on import wizard only after I saved a password not address and credit card.
Bug: NimbusRolloutMessageProvider should be listed as a generated file ( tools/rewriting/Generated.txt ) and updated automatically
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-10-16 13:59:32+00:00
Resolved: 2024-03-30 20:14:13+00:00

Per https://phabricator.services.mozilla.com/D190716?id=775524#inline-1058941 this file is generated, but it's not listed in Generated.txt and updates appear to be manual (and appear to so far not have happened).

We should also add a script a la the stuff in https://searchfox.org/mozilla-central/source/taskcluster/docker/periodic-updates so this runs once a day like other things that update based on remote settings.
Bug: Users are re-enrolled in a rollout after changing the feature configuration preference
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-10-16 14:55:57+00:00
Resolved: 2023-12-19 15:55:24+00:00

**[Affected versions]:**
- Firefox Release, 116.0 (BUILD ID: 20230727152340) 
- Firefox Release, 117.0, (BUILD ID: 20230824132758)
- Firefox Release, 118.0.2 (BUILD ID: 20231009140911)
- Firefox Beta 119.0b8 (BUILD ID: 20231011091528)
- Firefox Nightly 120.0a1 (BUILD ID: 20231002221644 )

**[Affected Platforms]:**
- MacOS 13.6 
- Windows 11 x64

**[Prerequisites]:** 
- Have the a rollout in preview state (e.g: https://stage.experimenter.nonprod.dataops.mozgcp.net/nimbus/feature-config-testing-for-racecachewithnetwork-treatment-a-rollout-copy/summary)
- Naturally enroll in the rollout. 

**[Steps to reproduce]:**
1. Navigate to the “about:config” page. 
2. Search for the pref changed by the rollout. (e.g: network.http.rcwn.enabled)
3. Change the pref to another value than set in the rollout. 
4. Restart the browser. 
5. Observe the results. 

**[Expected results]:**
- The rollout is disabled and the user is not re-enrolled after the restart. 

**[Actual results]:**
- The user is re-enrolled after the browser is restarted. 

**[Notes]:**
- This issue might be related to this [1833248.](https://bugzilla.mozilla.org/show_bug.cgi?id=1833248) 
- This issue is not reproducible with Firefox 114.  
- This issue is not reproducible with forced enrollment. 
- Attached a screen recording of the current behavior.
Bug: Replace `AppConstants.platform == "mac"` with `== "macosx"`
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-10-16 17:03:28+00:00
Resolved: 2023-12-04 08:06:01+00:00

There's a mistaken check at https://searchfox.org/mozilla-central/rev/81f368dab93fff035ce7fcc376e16990e89dd5ec/browser/components/preferences/main.js#3637.  The correct value is "macosx".

This is a good first bug: a one liner!
Bug: White flash when opening about:newtab with dark theme
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-10-16 17:06:10+00:00
Resolved: 2024-07-23 18:38:12+00:00

STR:
1. Enable the Dark theme.
2. Create a new tab (`about:newtab`). 
3. Refresh the page, duplicate the page or open many new tabs (hold Ctrl+T).

White flash before showing `about:newtab` content.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=80384e2c99e87006a2706b701a3185463685fe76&tochange=93cb4f911941645d91cf11ed1b0062f6e351c7f5

Regressed by Bug 1812135.
Bug: "Turn off review checker" button's text is not centered vertically
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-10-16 18:58:51+00:00
Resolved: 2023-10-26 12:22:37+00:00

See the attached screenshot. I bisected this bug to this pushlog for bug 1851833 to switch font sizes from in-content to chrome sizes:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0509c4b69da8703d9dbce645f0eb19e017b47e6a&tochange=d244d17a8e9ac94aa05c3bf0c2659104c7b15f76

I am using Firefox Nightly Windows 11.
Bug: Intermittent [Tier-2] browser/components/places/tests/browser/browser_bookmarkProperties_xulStore.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-10-16 18:59:22+00:00
Resolved: 2023-11-15 12:02:19+00:00

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

---
```
[task 2023-10-16T18:17:39.666Z] 18:17:39     INFO - TEST-PASS | browser/components/places/tests/browser/browser_bookmarkProperties_xulStore.js | Check the expected xulstore value - "true" == "true" - 
[task 2023-10-16T18:17:39.666Z] 18:17:39     INFO - Leaving test bound 
[task 2023-10-16T18:17:39.666Z] 18:17:39     INFO - Buffered messages finished
[task 2023-10-16T18:17:39.667Z] 18:17:39     INFO - TEST-UNEXPECTED-PASS | browser/components/places/tests/browser/browser_bookmarkProperties_xulStore.js | We expect at least one assertion to fail because this test file is marked as fail-if in the manifest. - 
[task 2023-10-16T18:17:39.668Z] 18:17:39     INFO - TEST-INFO | expected FAIL
[task 2023-10-16T18:17:39.675Z] 18:17:39     INFO - GECKO(26186) | MEMORY STAT | vsize 19957MB | residentFast 462MB | heapAllocated 353MB
[task 2023-10-16T18:17:39.676Z] 18:17:39     INFO - TEST-OK | browser/components/places/tests/browser/browser_bookmarkProperties_xulStore.js | took 462ms
```