av9ash/GitBugs huggingface dataset:
Bug: With all text in address bar selected, Ctrl-Shift-Left unselects everything after a delay
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-11-17 18:23:28+00:00
Resolved: 2024-11-17 20:11:57+00:00

Steps to reproduce:

- Press Ctrl-L to select all text in the address bar.
- Press Ctrl-Shift-Left to deselect the last word.
- The last word gets deselected, but a moment later, the entire address bar gets deselected.
Bug: Cleartext Storage and Persistent Memory Retention of Sensitive Data in Firefox
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-11-17 19:09:11+00:00
Resolved: 2024-11-27 19:17:58+00:00

This report identifies two security vulnerabilities in Firefox (Version 132.0.2) that compromise user privacy and security:      Cleartext Storage of Sensitive Information in Memory: Firefox stores sensitive user data, including passwords and API keys, in plaintext within memory, which can be accessed by unauthorized local attackers using memory inspection tools.      Persistent Data Retention from Closed Tabs: Even after closing tabs, including incognito mode, sensitive data remains in memory until the entire Firefox browser process is terminated. This exposes users to potential data extraction via memory analysis tools.

These vulnerabilities were discovered by analyzing Firefox's memory management behavior. The following steps outline the discovery process:

    Vulnerability 1: CWE-316 - Cleartext Storage of Sensitive Information in Memory:
        How Discovered: During analysis, it was found that Firefox stores user-provided and server-received sensitive information, such as login credentials and API keys, in plaintext in memory.
        Tools: Memory analysis tools like Process Hacker or Volatility were used to inspect Firefox's memory for sensitive data.
        Steps to Reproduce:
            Open Firefox and log into a sensitive website (e.g., PayPal) in a regular or incognito session.
            Use Process Hacker or a similar tool to inspect the memory of the Firefox process.
            Search for plaintext sensitive data such as passwords or API keys stored in memory.
            Firefox Version: 132.0.2
            Operating System: Windows 11 23H2 

    Vulnerability 2: Persistent Data Retention from Closed Tabs:
        How Discovered: It was observed that even after closing tabs, especially incognito sessions, sensitive data from those tabs remained accessible in memory until Firefox was fully terminated.
        Steps to Reproduce:
            Open Firefox and log into a website in incognito mode.
            After logging out and closing the incognito tab, leave other tabs open.
            Use memory analysis tools like Process Hacker to inspect the memory of the Firefox process and search for data from the closed tab.
            Sensitive data, such as session tokens or login credentials, will still be present in the memory of the Firefox process.
            Firefox Version: 132.0.2
            Operating System: Windows 11 23H2
Bug: Site Tracking and Permissions Buttons Are Inaccessible Via Keyboard Navigation if the Unified Search Button Has Focus
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-11-18 01:00:56+00:00
Resolved: 2024-11-22 00:55:27+00:00

### STR

1. Enable `browser.urlbar.scotchBonnet.enableOverride`.
2. Navigate to a site (e.g. https://example.com).
3. Navigate to the Unified Search Button via keyboard navigation.
4. Navigate to one of the information buttons (e.g. the protections button) via keyboard navigation.

### Expected Results

SHIFT+TAB should allow the focus to move from the Unified Search Button to the next adjacent information button.

### Actual Results

The information buttons are no longer a TAB stop.
Bug: URL page zoom indicator weirdness
Status: UNCONFIRMED
Priority: --
Created: 2024-11-18 02:32:36+00:00
Resolved: 2025-02-28 22:39:18+00:00

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

Steps to reproduce:

The zoom level indicator has persistence issues. It seems that it is only updated when changing the zoom level or opening a new tab, but not in other cases where it should.


1. Switching from a zoomed tab (zoom indicator visible) to a different tab does not change the zoom level/visibility of the zoom indicator.
2. Closing a zoomed tab does not cause the zoom indicator to update.
3. Opening a new tab with ctrl+T or ctrl+U makes the zoom indicator disappear.
4. The zoom indicator will not disappear when attempting to reset the zoom level of a tab that is already at 100%.

At least some of these have existed for a while and I never got around to reporting until now.
Bug: Newtab section cards have semantically incorrect element for card title
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-11-18 03:53:05+00:00
Resolved: 2024-11-26 20:35:26+00:00

In New Tab's section cards, the title of the card is a `header` element instead of a heading element (i.e. `h3` or `h4`).
The `header` element is supposed to represent an introductory section of a page, but in this case it is being used as a wrapper for a heading title of the card content. 

To reproduce:
- Open a New Tab page on a Firefox web browser (ctrl + t // cmd + t)
- You should be seeing section card content containing articles in each card. If you don't have it enabled, go to `about:config` and make sure you have `browser.newtabpage.activity-stream.discoverystream.sections.cards.enabled` and `browser.newtabpage.activity-stream.discoverystream.sections.enabled` set to **true**
- Hover over a card and right click, select "inspect element"
- Go to the title of the card, notice it is wrapped in a `header` element
Bug: Newtab section cards anchor tag improperly positioned
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-11-18 05:25:51+00:00
Resolved: 2024-12-19 05:07:27+00:00

In the Firefox New Tab page, the card sections contain an anchor tag, containing the article link, is intended to make the cards interactive. However, the anchor tag is currently positioned absolute with `width: 100%` and `height: 100%`, covering the entire card. This implementation is problematic because:

- It does not wrap the actual content of the card, which is what should be interactive.
- The use of  `position: absolute` and covering the card entirely can lead to unexpected behaviors or accessibility issues, especially for screen readers and keyboard navigation.

Expected Behavior:
- The anchor tag should wrap around the content of the card to properly associate the interactive area with corresponding content 
- The anchor should not have to rely on absolute positioning to make the entire card interactive.

Actual Behavior:
- The anchor tag is positioned absolutely over the card, with `width: 100%` and `height: 100%`, instead of wrapping the content.

Steps to Reproduce:
- Open a new tab in Firefox.
- Inspect any card section in the new tab page.
- Observe that the anchor tag does not wrap around the content and instead spans the entire card using absolute positioning.
Bug: [win10] The Bookmark star icon is not visible on hover with High Contrast if the page is bookmarked
Status: NEW
Priority: P2
Created: 2024-11-18 10:04:32+00:00
Resolved: 2025-01-14 16:25:11+00:00

**Found in**
* 134.0a1 (2024-11-17)

**Affected versions**
* 134.0a1 (2024-11-17)
* 133.0b9	
* 132.0.1
* 128.4.0esr

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

**Precognitions**
* OS High contrast enabled (reproducible with all 4 options)
* Firefox System theme enabled


**Steps to reproduce**
1. Bookmark a random page and hover the bookmark button.

****Expected result****
* The star icon is visible.

**Actual result**
* The star icon is not visible.



**Regression range**
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fe7af5b078750f8394e5dbb4333a8c1471c9af66&tochange=6c6258954d92b34174ed0fb95bb92107a5c602ad 


**Additional notes**
* Attached a screen recording.
Bug: [Remote Message] The "Not Now" buttom from the Fx 91-101 non-en infobar has the "[object Object]" string
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-11-18 13:04:11+00:00
Resolved: 2024-12-10 02:39:18+00:00

**[Affected versions]:**
- Firefox Release 101.0.1 (Build ID 20220608170832)

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

**[Prerequisites]:**
- Have the "root-ca" pref set to any value.
- Have a non-en* build installed (e.g. de locale)

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Open a new tab and observe the address bar.

**[Expected result]:**
- The infobar is displayed and all elements are translated in the installed locale.

**[Actual result]:**
- All elements are translated except for the "Not Now" button which has the "[object Object]" string.

**[Notes]:**
- The issue is reproducible using multiple locales.
- The issue is NOT reproducible using the ESR version of the message.
- Attached a screenshot of the issue:
Bug: "Tab sent" notification no longer displays after sending tab to another device
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-11-18 13:12:15+00:00
Resolved: 2024-12-10 14:13:11+00:00

I'm pretty sure when I used to send tabs from Desktop Firefox I would see a "Tab sent!" overlay appear briefly, but now when I send one I see no such notification.

I mentioned this in the Nightly room on Matrix and one other user acknowledged they seem to recall the same behavior but no longer see it.

I'm on Nightly 134.0a1 (2024-11-14) (64-bit)
Bug: Newtab ensure if Unified ads API is turned on and off, we keep the state and experience consistent.
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-11-18 13:44:34+00:00
Resolved: 2024-11-19 10:05:23+00:00

Right now if Unified ads is toggled on and off, we don't update open tabs or state, so some old API ads are still in the system.

This is specifically topsites. DiscoveryStream ads do watch for the pref change.

We should sync this when the pref changes.
Bug: Attention dot isn't visible when user-installed theme uses `#54ffbd` for the nav-bar
Status: NEW
Priority: P3
Created: 2024-11-18 13:56:55+00:00
Resolved: 2024-11-20 19:21:27+00:00

## STR

1. Install a theme that uses `#54ffbd` for the color of the nav-bar (toolbar color). (I used https://color.firefox.com)
2. Get an attention dot on some button, e.g. on the extensions button (I added a domain to the `extensions.quarantinedDomains.list` pref temporarily to force the attention do to show up when navigating to this domain, you also need other non-recommended extensions installed)

## Expected

Attention dot is visible.

## Actual

Attention dot is invisible.
Bug: Firefox Nightly 134.0a1 (2024-11-18) (64-bit) visual bugs on windows 11
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-11-18 15:39:31+00:00
Resolved: 2024-12-11 19:27:36+00:00

Latest nightly version of firefox nightly 134 on windows 11 seems to be missing the rounded corners of windows 11 and the drop shadow effect + windows coloured windows border
Bug: Intermittent browser/components/tabbrowser/test/browser/tabs/browser_multiselect_tabs_unload_telemetry.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2024-11-18 16:39:43+00:00
Resolved: 2024-12-09 06:17:24+00:00

**Filed by:** smolnar [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=483143923&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/CdJbeFsjTgCa8sajpnHh1w/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/CdJbeFsjTgCa8sajpnHh1w/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
TEST-PASS | browser/components/tabbrowser/test/browser/tabs/browser_multiselect_tabs_unload_telemetry.js | correct number of tabs unloaded - "1" == "1" - 
[task 2024-11-18T16:00:32.870Z] 16:00:32     INFO - Leaving test bound test_unload_one_unselected_tab
[task 2024-11-18T16:00:32.870Z] 16:00:32     INFO - Entering test bound test_unload_selected_tab
[task 2024-11-18T16:00:32.871Z] 16:00:32     INFO - Buffered messages finished
[task 2024-11-18T16:00:32.871Z] 16:00:32     INFO - TEST-UNEXPECTED-FAIL | browser/components/tabbrowser/test/browser/tabs/browser_multiselect_tabs_unload_telemetry.js | Test timed out - 
[task 2024-11-18T16:00:32.872Z] 16:00:32     INFO - GECKO(1051) | Completed ShutdownLeaks collections in process 1051
[task 2024-11-18T16:00:32.872Z] 16:00:32     INFO - TEST-START | Shutdown
```
Bug: ctrl + shift + tab doesn't navigate to previous tab when the urlbar has focus
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-11-18 17:23:51+00:00
Resolved: 2024-12-17 15:33:24+00:00

Ctrl + shift + tab doesn't navigate to previous tab when the url bar has focus, but focusses dedicated search button first. Only second ctrl+shift+tab navigates to previous tab.

STR:

1. Open multiple tabs
2. focus urlbar with ctrl+l
3. try to navigate to previous tab with ctrl+shift+tab

Result: search icon is focussed 
Expected result: previous tab is opened

If I read Bug 1921174 correctly, then ctrl+shift+tab shouldn't focus the search icon, only shift+tab should
Bug: "Manage extension" right click context menu shown for new sidebar
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-11-18 19:06:46+00:00
Resolved: 2025-01-17 08:05:53+00:00

With the new sidebar enabled via Preferences->Firefox Labs->Sidebar, when right-clicking on the sidebar below the icons (see screenshot), a "Manage extension" context menu is displayed. Unless the right-click is on an extension that has been installed, the menu should not be displayed for the built-in side bar because it is not an extension that can be managed.

Sometimes the problem goes away and the menu does not activate.

Problem hit on Nightly 134.0a1 (2024-11-18) on macOS.
Bug: Bookmarks in "Other Bookmarks" folder disappeared after updating to Firefox 132.0.2
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-11-18 21:42:09+00:00
Resolved: 2025-01-07 16:37:20+00:00

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

Steps to reproduce:

1. Saved bookmarks in the "Other Bookmarks" folder, organized into several subfolders.
2. Updated Firefox to version 132.0.2.
3. Attempted to add a new bookmark to "Other Bookmarks" and noticed the entire folder and its contents were missing.


Actual results:

-The "Other Bookmarks" folder is completely empty.
-Backups (bookmarkbackups) and the places.sqlite database do not contain the missing bookmarks.
-Default bookmarks and a single old bookmark (unrelated to "Other Bookmarks") are present in the "Bookmarks Menu" folder.
-Other profiles on the same system do not contain the missing bookmarks.


Expected results:

-Bookmarks stored in the "Other Bookmarks" folder, along with their folder structure, should persist after the Firefox update.
Bug: [win] One click default is not working on one Windows 11 machine
Status: NEW
Priority: P3
Created: 2024-11-19 08:20:40+00:00
Resolved: 2024-11-20 00:08:27+00:00

**Found in**
* 134.0a1 (2024-11-18)

**Affected versions**
* 134.0a1 (2024-11-18)
* 133.0
* 132.0	.1
* 128.4.0esr

**Tested platforms**
* Affected platforms: Windows 11 (ARM) - only on one machine
* Unaffected platforms: Windows 11, Windows 10x64, macOS 12, Ubuntu 24

**Precognitions**
* Firefox is not the default browser


**Steps to reproduce**
1. Make Firefox the default browser.

****Expected result****
* Firefox is made default in one click.

**Actual result**
* Windows Settings > Default Apps is opened.



**Regression range**
* I don’t think this is applicable because this may be a Windows change. I can reproduce the issue with 126.0.


**Additional notes**
* Attached a screen recording.
* I am reproducing the issue only on a Windows 11 24H2 (Build 26100.2448) ARM machine. However, I tested on another AMD-based machine with Windows 11 24H2 (26100.2314), and the issue does not occur. Additionally, we tested on other Windows 11 ARM machines and Windows 10 machines, but the issue could not be reproduced on those either. This may be a Microsoft rollout.
* This reproduces with normal builds and MSIX builds.
Bug: [Remote Message] The Fx 86-87 infobar has a blank title on the en-CA locale
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-11-19 10:18:22+00:00
Resolved: 2024-12-10 02:39:25+00:00

**[Affected versions]:**
- Firefox Release 86.0.1 (Build ID 20210310152336)

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

**[Prerequisites]:**
- Have the "root-ca" pref set to any value.
- Have an en-CA build installed.

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Open a new tab and observe the address bar.

**[Expected result]:**
- The infobar is triggered and all elements are displayed according to the installed locale.

**[Actual result]:**
- The infobar's title is blank.

**[Notes]:**
- For now, it appears that it's only reproducible on en-CA locale, the following locales are not affected: en-US, en-GB, fr, ru, zh-CN.
- If the translated string is not available, the message should have a fallback to prevent empty strings.
- Attached a screenshot of the issue:
Bug: Target language missing in certain case
Status: NEW
Priority: P3
Created: 2024-11-19 10:59:28+00:00
Resolved: 2024-12-03 16:24:38+00:00

See attached video. When translating (e.g.) from a detected language (here English) to French, then copying the French sentence in the destination input to the source input, French is correctly detected, but English is missing from the destination language drop down.
Bug: closed window as "new tab" is not stored in browsing history
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-11-19 11:00:59+00:00
Resolved: 2024-12-04 06:54:24+00:00

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

Steps to reproduce:

Open a new window, leave it empty.
Close the window.
Press Ctrl+Shift+T


Actual results:

nothing.


Expected results:

even with only a new tab in a window, upon closing the window, it should be saved in browsing history under recently closed windows.
Bug: The text from some of the Sidebar Microsurvey slides is missing on en-US locales
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-11-19 13:09:42+00:00
Resolved: 2024-12-04 14:16:05+00:00

[Affected versions]:
- Firefox Nightly 134.0a1, BUILD ID: 20241118213357.

[Affected Platforms]:
- Windows 10.
- Ubuntu 22.04.
- macOS 14.7.

[Prerequisites]:
- The new Sidebar is enabled from the “Firefox Labs” screen (about:preferences#experimental).
- User is enrolled in the “[134 Sidebar microsurvey](https://experimenter.services.mozilla.com/nimbus/134-sidebar-microsurvey/summary)” rollout on a new profile.
- Locale of the browser is en-US.

[Steps to reproduce]:
1. Open the browser with the profile from the prerequisites.
2. Click any of the tools displayed in the sidebar 4 times (by default, only “History” and “Tabs from other devices” are available).
3. Click any tool from the sidebar for the 5th time and trigger the microsurvey.
4. Progress through the microsurvey slides and observe the behavior.

[Expected result]:
- All the text from the microsurvey is displayed accordingly.

[Actual result]:
- The text for the answers from some of the microsurvey slides is missing.

[Regression window]:
- Last good revision: 4424e72e5872e8fdfa2cfba982240bace917fe72
- First bad revision: b25ce25984e4bcf89b8fa7bc38da7f34b58c35ca
- Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4424e72e5872e8fdfa2cfba982240bace917fe72&tochange=b25ce25984e4bcf89b8fa7bc38da7f34b58c35ca

[Additional Notes]:
- Messages such as “[fluent] Missing message in locale en-US: sidebar-callout-survey-very-dissatisfied” can be seen in the console logs.
- This issue is reproducible with the Right Position [microsurvey](https://experimenter.services.mozilla.com/nimbus/134-sidebar-microsurvey-right-position/summary) as well.
- This issue is not reproducible with a fr locale for example.
- This issue is not reproducible using an older Firefox Nightly build.
Bug: [Experiment] The Sidebar + Gen AI card is displayed twice on the onboarding screen
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-11-19 13:46:37+00:00
Resolved: 2024-11-20 07:56:21+00:00

**[Affected versions]:**
- Firefox RC, 133.0, BUILD ID: 20241118181856

**[Affected Platforms]:**
- Windows 11 x64
- Windows 10 x64


**[Prerequisites]:**
- Have the [“user.js”](https://drive.google.com/drive/folders/1uLoV0e9MzERm57zkGvarMJ3OpflPspTe )  downloaded on your computer. 

**[Steps to reproduce]:**
1. Create a new Firefox profile using the “--first-startup” command but do not open it.
2. Navigate to the profile folder and paste the user.js from the prerequisites. 
3. Open Firefox and navigate through the “about:welcome” cards. 


**[Expected results]:**
- The “Sidebar + Gen AI” card is displayed only once.  

**[Actual results]:**
- The “Sidebar + Gen AI” card is displayed twice for each option. 

**[Notes]:**
- This issue is reproducible only on the Treatment B branch of the experiment. 
- Attached is a recording of the issue.
Bug: "Clear cookies and site data" in the identity panel should not clear across containers and PBM modes
Status: NEW
Priority: P3
Created: 2024-11-19 13:46:44+00:00
Resolved: 2024-11-20 21:21:24+00:00

Currently when using the clear site data option in the identity panel (lock icon) we clear all data for the given (schemeless) site across all OriginAttributes. This seems unexpected. For example, if I have a container tab open and clear the current site it should really only clear the given site in the current container. Same for PBM / non PBM. If I'm in private browsing that option should only clear private browsing data for the given site.

Now that our ClearDataService is updated it can target OriginAttributes by pattern. This means that the caller for the "clear cookies and site data" option can pass a pattern to restrict clearing to the current tab's context. For example it could call `cds.deleteDataFromSite("example.com", { userContextId: 1 }, [...]);`.
Note that this isn't quite correct though. The second argument is a `OriginAttributesPattern` where omitted properties act as wildcards.  If only `{userContextId: 1}` is passed we would still clear across normal / private browsing boundaries. We really want to clear by site + exact `OriginAttriutes`. This can be achieved with a pattern as well, we just have to do a bit more work:

```javascript
// click / command handler of "Clear cookies and site data button"
let originAttributes = gBrowser.contentPrincipal.originAttributes;
// Filling up the OA means we set all OriginAttributes explicitly which effectively makes the OA pattern make an exact OA match.
let filledOAPattern = ChromeUtils.fillNonDefaultOriginAttributes(originAttributes);
clearDataServices.deleteDataFromSite(gBrowser.contentPrincipal.baseDomain, filledOAPattern, [...]);
````
Bug: Full keywords should not bypass length threshold for Sponsored Suggestion Higher Placement Phase 3
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-11-19 20:44:06+00:00
Resolved: 2024-11-20 09:41:49+00:00

Bug 1913507 included a condition in Firefox’s “should show AMP as top pick?” logic that will show a top pick if the full keyword is typed, even if the full keyword length < the threshold length. That was an error I think, due in part to me misunderstanding what “full keyword” means. The full keywords stored in remote settings and returned by the Rust component are not what you would intuitively think of as "full keywords". They usually aren't full phrases and often aren't even full words. We should remove that condition.