av9ash/GitBugs huggingface dataset:
Bug: Newtab minor console error related to wallpaper v1 removal
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-03-04 06:34:26+00:00
Resolved: 2025-03-04 21:38:29+00:00

Seeing this error "JavaScript error: resource://newtab/data/content/activity-stream.bundle.js, line 13454: TypeError: undefined has no properties"

Looks like this is due to https://searchfox.org/mozilla-central/source/browser/extensions/newtab/content-src/components/Base/Base.jsx#435-436

```
        // Grab the contrast of the currently displayed wallpaper.
        const { theme } =
          this.state.colorMode === "light" ? lightWallpaper : darkWallpaper;
```

Essentially if the user has no wallpaper set, lightWallpaper/darkWallpaper are undefined.

```
      let lightWallpaper;
      let darkWallpaper;
```

Preciously they would be empty strings in this case, which is also not correct, and probably why we didn't notice this error.

The console error itself is also harmless, currently, because the rest of the code in this function isn't necessary for the case of no wallpaper being set, but we should clear it up anyway.

We should fix it with something like this:

```
      let lightWallpaper = {};
      let darkWallpaper = {};
```
Bug: Cannot edit existing search shortcut
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-03-04 09:43:27+00:00
Resolved: 2025-03-05 07:31:44+00:00

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

Steps to reproduce:

1. Add a custom search shortcut
2. Double or right mouse click on the new shortcut to edit it


Actual results:

I cannot edit the shortcut, only delete.


Expected results:

I expect to edit it.
Bug: The Unsupported website version of "Can you trust these reviews" panel is displayed on Supported websites after switching to that tab and reopening the RC panel
Status: ASSIGNED
Priority: P2
Created: 2025-03-04 09:53:17+00:00
Resolved: 2025-03-05 06:06:42+00:00

**Found in**
* 138.0a1 (2025-03-03)

**Affected versions**
* 138.0a1 (2025-03-03)

**Affected platforms**
* all

**Preconditions**
Enable the Review Checker:
browser.shopping.experience2023.enabled - true
browser.shopping.experience2023.optedIn - 1
browser.shopping.experience2023.autoOpen.enabled - true
browser.shopping.experience2023.integratedSidebar - true
browser.shopping.experience2023.shoppingSidebar - false

**Steps to reproduce**
1. Open the Review Checker in the Sidebar on an Unsupported Website.
2. Reach Amazon.com and notice the text.
3. Close the RC panel and switch to a Tab with an unsupported website.
4. Open the RC Panel.
5. Switch back to the Amazon tab and open the RC panel

**Expected result**
* The Can you trust these reviews ? panel should be different on Supported or unsupported websites.

**Actual result**
* After switching to a tab with the Supported website from the unsupported website tab, RC will show the Message from the unsupported website.

**Regression range**
Not a regression.
Bug: [Firefox 136] Shortcuts on the new tab page have taken a massive hit and look horrible
Status: UNCONFIRMED
Priority: --
Created: 2025-03-04 10:52:32+00:00
Resolved: 2025-03-04 17:07:23+00:00

Steps to reproduce:

These two screenshots are taken on the same device, with the same resolution and the same zoom.

**Why have you broken shortcuts?**





Actual results:

Firefox 136:
 * Every icon is now SMALLER
 * Everything is extremely cramped
 * Font is much smaller and barely readable


Expected results:

Firefox 135: looks fine
Bug: The "Search with" row is expanded when typing a keyword while the opt-in message is displayed
Status: ASSIGNED
Priority: --
Created: 2025-03-04 13:43:09+00:00
Resolved: 2025-03-05 22:01:14+00:00

**[Affected versions]:**
- Firefox Release 136.0 (Build ID: 20250225123537)
- Firefox Beta 137.0b7 (Build ID: 20250303103151)
- Nightly 138.0a1 (Build ID: 20250219215346)

**[Affected Platforms]:**
- Windows 10 x64
- MacOS 14.7.1
- Linux Mint 20.1

**[Prerequisites]:**
- Have a Firefox Beta 137 en-US build installed/extracted.
- Have the following prefs set:
 - browser.search.region = US
 - browser.urlbar.quicksuggest.contextualOptIn = true

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Click in the addressbar. 
3. While the opt-in message is displayed, type any keyword.
4. Observe the "Search with" result.

**[Expected result]:**
- The "Search with" result has the same dimensions as the other results.

**[Actual result]:**
- The "Search with" result is extended and has the dimensions of the opt-in message.

**[Notes]:**
- This issue is also reproducible on Firefox Release 136.0.
- Attached is a screen recording of the issue.
Bug: The contextual opt-in message is displayed for a moment when re-focusing the addressbar after the message previously dismissed
Status: ASSIGNED
Priority: --
Created: 2025-03-04 13:45:10+00:00
Resolved: 2025-03-05 22:25:18+00:00

**[Affected versions]:**
- Firefox Beta 137.0b7 (Build ID: 20250303103151)
- Nightly 138.0a1 (Build ID: 20250219215346)

**[Affected Platforms]:**
- Windows 10 x64
- MacOS 14.7.1
- Linux Mint 20.1

**[Prerequisites]:**
- Have a Firefox Beta 137 en-US build installed/extracted.
- Have the following prefs set:
 - browser.search.region = US
 - browser.urlbar.quicksuggest.contextualOptIn = true

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Click in the addressbar. 
3. Click the "Not now" button.
4. Click again in the addressbar.
5. Observe the behavior.

**[Expected result]:**
- The opt-in message is no longer displayed.

**[Actual result]:**
- The opt-in message is displayed for a moment, then disappears. 

**[Notes]:**
- The issue is NOT reproducible on Firefox Release 136, it seems that it was introduced with the latest updates. 
- The issue is reproducible in both cases if the "Allow Suggestions" or "Not Now" button is clicked.
- Attached is a screen recording of the issue.
Bug: Broken nested span blending
Status: NEW
Priority: --
Created: 2025-03-04 14:01:18+00:00
Resolved: 2025-03-04 15:34:33+00:00

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

Steps to reproduce:

Currently, if we wrap some text in a paragraph in a `span`, give it a `background` and a big enough `padding`, then its `background` [visually covers the previous line](https://codepen.io/patrickhlauke/pen/jOzJwvZ).

In case we only wrap into spans isolated words, a simple fix if we have black text is:

```
p { isolation: isolate }
span { mix-blend-mode: darken }
```

This blends the `span`'s `background` with the `black` paragraph text around the `span` and prevents blending with anything outside the paragraph (like with an image background on the `body`). [Live demo](https://codepen.io/thebabydino/pen/ogNzGpw) illustrating this.

For longer spans that wrap, this doesn't work anymore. To go around this, we wrap the `span` in another `span`, and set the `background` and the `padding` just on the outer `span`.

```
p { isolation: isolate }

p > span {
  background: hotpink, crimson;
  padding: .5em .125em
}

span { mix-blend-mode: darken }
```


Actual results:

We still have the overlap problem in Firefox. [Live test](https://codepen.io/thebabydino/pen/azbpKpg).


Expected results:

Now not only should the outer `span`'s `background` get blended with the `black` paragraph text outside the `span`, but in this case, the `black` inner `span` text should get blended with the `background` of the outer span, fixing the overlap problem.

This is what happens in both Chrome and Safari.
Bug: Intermittent browser/components/shopping/tests/browser/browser_reviewchecker_new_position_notification_card.js | single tracking bug
Status: NEW
Priority: P5
Created: 2025-03-04 14:24:48+00:00
Resolved: 2025-03-04 14:24:48+00:00

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

---
```
[task 2025-03-04T13:42:25.198Z] 13:42:25     INFO - TEST-PASS | browser/components/shopping/tests/browser/browser_reviewchecker_new_position_notification_card.js | Sidebar is open now - true == true - 
[task 2025-03-04T13:42:25.198Z] 13:42:25     INFO - Buffered messages finished
[task 2025-03-04T13:42:25.198Z] 13:42:25     INFO - TEST-UNEXPECTED-FAIL | browser/components/shopping/tests/browser/browser_reviewchecker_new_position_notification_card.js | Test timed out - 
[task 2025-03-04T13:42:25.198Z] 13:42:25     INFO - GECKO(4680) | Completed ShutdownLeaks collections in process 4680
[task 2025-03-04T13:42:25.198Z] 13:42:25     INFO - TEST-START | Shutdown
```
Bug: Tags that start with equal sign (=) contain all entries from the browser history
Status: UNCONFIRMED
Priority: --
Created: 2025-03-04 14:42:44+00:00
Resolved: 2025-03-04 15:48:06+00:00

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

Steps to reproduce:

1) Created fresh profile;
2) Started Firefox with new profile;
3) Added a bookmark for "https://www.mozilla.org/ru/privacy/firefox/";
4) Added tags to the new bookmark: "~qwe,#qwe,+qwe,=qwe";
5) Cleared the browser history;
6) Visited a few random websites.


Actual results:

In Firefox Library tags "~qwe", "#qwe" and "+qwe" contain the newly added bookmark. Tag "=qwe", however, contains entries from the browser history, but not the bookmark that was tagged with it.


Expected results:

All four tags should've contained that new bookmark and nothing else.
Bug: Sanitizing dialog accessible via 2 buttons in about:preferences#privacy does not share the same settings for remembering checkboxes
Status: UNCONFIRMED
Priority: --
Created: 2025-03-04 16:40:38+00:00
Resolved: 2025-03-04 16:42:02+00:00

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

Steps to reproduce:

1. Go to about:preferences#privacy .
2. Click one of the 2 buttons to delete your history to open the sanitizing dialog.
3. Enable all checkboxes and delete your history.
4. Open the sanitizing dialog via the other button in about:preferences#privacy .


Actual results:

The checkboxes have not been remembered as they appear to use different settings for each sanitizing dialog despite looking the same.


Expected results:

The checkboxes should have been remembered.
Bug: [Experiment] The “Turn on Syncing…” and the new Sync UI options are displayed in the FxA panel at the same time
Status: NEW
Priority: --
Created: 2025-03-04 17:11:26+00:00
Resolved: 2025-03-05 23:16:04+00:00

**[Affected versions]:**
- Firefox Release 136.0 (Build ID: 20250227124745)

**[Affected Platforms]:**
- Windows 11 x64
- Ubuntu 20.04 x64

**[Prerequisites]:**
- Have Firefox 136 installed.
- Be enrolled in the treatment-a branch of the [experiment](https://experimenter.services.mozilla.com/nimbus/new-sync-setup-flow/summary) (paste the user.js [file](https://drive.google.com/file/d/1T66_whRXWRHEnFxHRQXh3DSgQO9FXnr7/view?usp=sharing) in the Profile Folder, then restart the browser)).
- Create or have access to an existing Firefox Account (FxA).

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Log into the FxA from the prerequisites.
3. Click the FxA button from the toolbar.
4. Click the “Sync Settings” option.
5. Click the “Manage sync” button.
6. Click the “Disconnect…” button and save the preference.
7. Restart the browser.
8. Click the FxA button from the toolbar.
9. Observe the Sync section from the FxA panel.

**[Expected result]:**
- Only the new Sync design is displayed, with a bigger CTA “Turn On” button.

**[Actual result]:**
- The “Turn on Syncing…” option is displayed as well.

**[Notes]:**
- I was not able to reproduce the issue on **macOS 15.1**.
- [Here](https://drive.google.com/file/d/17RXnGfmbouD4E0KHLaqeIzp2qxsf_Hk0/view?usp=sharing) is a screen recording with the issue.
Bug: [Experiment] [Intermittent] The “Turn on Syncing…” option is displayed in the FxA panel even though Sync is already Turned ON in the preferences
Status: NEW
Priority: --
Created: 2025-03-04 17:17:39+00:00
Resolved: 2025-03-04 17:17:39+00:00

**[Affected versions]:**
- Firefox Release 136.0 (Build ID: 20250227124745)

**[Affected Platforms]:**
- Windows 11 x64
- Ubuntu 20.04 x64

**[Prerequisites]:**
- Have Firefox 136 installed.
- Be enrolled in the treatment-a branch of the [experiment](https://experimenter.services.mozilla.com/nimbus/new-sync-setup-flow/summary) (paste the user.js [file](https://drive.google.com/file/d/1T66_whRXWRHEnFxHRQXh3DSgQO9FXnr7/view?usp=sharing) in the Profile Folder, then restart the browser)).
- Create or have access to an existing Firefox Account (FxA).

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Log into the FxA from the prerequisites.
3. Navigate to the “about:preferences#sync” page.
4. Make sure that the Sync status is ON.
5. Click the FxA button from the toolbar.
6. Observe the Sync options.

**[Expected result]:**
- The “Turn on Syncing…” option is not displayed in the panel since sync is already ON.

**[Actual result]:**
- The “Turn on Syncing…” option is displayed in the FxA panel.

**[Notes]:**
- Restarting the browser makes the “Turn on Syncing…” option disappear from the FxA panel.
- I was not able to reproduce the issue on **macOS 15.1**.
- [Here](https://drive.google.com/file/d/1L3Zlb2ORY3FlGrnebYQPEny0muLvErHC/view?usp=sharing) is a screen recording with the issue.
Bug: Cmd + Return no longer opens search in new tab as of 136.0
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-03-04 19:49:40+00:00
Resolved: 2025-03-05 15:28:19+00:00

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

Steps to reproduce:

1. Highlight the search bar; type a word into it.
2. Press Cmd + Enter.


Actual results:

Firefox navigates to the word surrounded with "www." and ".com".


Expected results:

Firefox searches for the word in a new tab.
Bug: "vertical tabs" doesn't work properly with browser.theme.windows.accent-color-in-tabs.enabled
Status: UNCONFIRMED
Priority: --
Created: 2025-03-04 22:39:39+00:00
Resolved: 2025-03-04 22:42:21+00:00

The windows accent color is intended for the title bar, which in the case of horizontal tabs includes the menu bar and the tab bar.

"vertical tabs" causes the tab sidebar, the command bar and the bookmark bar to be accent colored. These are not a part of the title bar and should not be accent colored.

The pref could also perhaps be renamed as it's no longer connected to tabs which can now be in the side bar. Something like "accent-color-in-title-bar-area".
Bug: Undo "Restore Defaults" does not correctly restore toolbar
Status: UNCONFIRMED
Priority: --
Created: 2025-03-05 04:42:52+00:00
Resolved: 2025-03-05 05:51:48+00:00

Steps to reproduce:

1. Right click on toolbar and select "Customize toolbar"
2. Click "Restore Defaults"
3. Change your mind and click "undo"



Actual results:

Toolbar items did not restore to the correct position and extensions pinned to the toolbar became very large. Restore Defaults also put my tabs back to horizontal and they stay horizontal after clicking undo.

Closing the window and/or quitting Firefox does seem to put the toolbar back in place, but not the tabs.

I tested this on macOS Nightly 138.0a1 and Windows 136.0


Expected results:

The toolbar should look the same as before you started.
Bug: moveToElement and click Actions Not Working in Firefox 135
Status: UNCONFIRMED
Priority: --
Created: 2025-03-05 05:09:15+00:00
Resolved: 2025-03-05 05:15:12+00:00

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

Steps to reproduce:

Product: Firefox
Component: WebDriver
Version: 135.0
Platform: (Your OS, e.g., Windows 11 / Ubuntu 22.04)

Description:
In Firefox 135, Selenium WebDriver's moveToElement and click actions are not functioning correctly. These actions previously worked in older Firefox versions but are now inconsistent or fail entirely.

Steps to Reproduce:

1.Initialize a Selenium WebDriver session using geckodriver.
2.Navigate to a web page containing an element that requires moveToElement before clicking.
3.Use the following Selenium code to move to the element and click

WebDriver driver = new FirefoxDriver();
Actions actions = new Actions(driver);
WebElement element = driver.findElement(By.id("your-element-id"));
actions.moveToElement(element).click().perform();

4.Observe the behavior.


Actual results:

The hover action does not work properly.
Click is either not registered or behaves inconsistently.
Works fine in older Firefox versions.



Expected results:

The element should be hovered over, and the click action should be successfully performed.

Works fine in other browsers .Issue in Firefox alone.
Bug: Accessibility focus gets confused when collapsing a tab group with the keyboard while a tab inside it is active
Status: NEW
Priority: --
Created: 2025-03-05 05:16:47+00:00
Resolved: 2025-03-05 05:16:47+00:00

STR (with the NVDA screen reader, but any screen reader should show similar results):

1. Open example.com and mozilla.org in two tabs.
2. Put mozilla.org in a tab group called test.
3. Switch to the mozilla.org tab.
4. Focus the tab bar. Focus should be on the mozilla.org tab.
5. Press left arrow to move to the button to toggle the test tab group.
6. Press space to collapse the tab group.
    - Expected: NVDA should announce that the button is collapsed.
    - Actual: NVDA announces that focus is on the Example Domain tab.
7. Since focus is apparently on the Example Domain tab, press right arrow to focus the test tab group button again.
    - Expected: if focus really had been on the Example Domain tab, NVDA should announce focus on the button. But see below.
    - Actual: Nothing happens.

I'm fairly sure focus isn't really on the Example Domain tab in step 6. This just happens because that tab becomes active, since the previously active tab was removed from the tab bar due to its group being collapsed. Although DOM focus goes to that newly active tab, pseudo-focus is still on the tab group button. I can confirm this by pressing space and then right arrow, which expands the tab group (though NVDA says nothing since it's not focused) and then moves to the mozilla.org tab in that group.

I think the fix here is to ensure that when a tab group is collapsed, if that causes another tab to become active, aria-activedescendant must be set on that newly active tab, pointing to the tab group button that has pseudo-focus.
Bug: Tabs in a collapsed tab group remain in the accessibility tree
Status: NEW
Priority: --
Created: 2025-03-05 05:34:41+00:00
Resolved: 2025-03-05 05:34:41+00:00

STR (with the NVDA screen reader, but I'm almost certain this will be true for VoiceOver as well):

1. Open a tab with example.com and move it into a tab group.
2. Focus the tab bar, arrow to the button to toggle the tab group and press space to collapse it.
3. Use the screen reader's command to move to the next object (NVDA desktop: NVDA+numpad6, NVDA laptop: NVDA+shift+rightArrow, VoiceOver: VO+rightArrow).
    - Expected: The screen reader should report the Open a new tab button.
    - Actual: The screen reader reports the Example Domain tab.

When a tab group is collapsed, it seems its `<tab>` elements aren't removed from the DOM and are still rendered by layout; i.e. they don't have hidden, display: none or similar. They just have a width of 0, so they aren't visible. This means they are still in the accessibility tree, which is incorrect because they shouldn't be perceivable semantically given that the tab group is collapsed.

Ideally, these should have hidden or display: none or the like. If that isn't a feasible implementation, they should get aria-hidden="true" until the tab group is expanded again.
Bug: Padding around new tab shortcuts
Status: UNCONFIRMED
Priority: --
Created: 2025-03-05 09:59:11+00:00
Resolved: 2025-03-05 10:16:10+00:00

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

Steps to reproduce:

I updated Firefox to 136.0




Actual results:

I have a 4k monitor and have split Windows left and right, width 2308 and 1532 respectively.

With 136.0 and (at least) one other recent update Firefox has (at least) twice changed the left and right padding around the shortcuts in a new tab, resulting in less shortcuts being shown (or having to zoom out) on the right windown to get all 8 columns. (Or: at 100% zoom resulting in a different number of shortcuts being shown on the left and the right window.)

With today's update, the new tab on the window on the right (when zoomed 100%) didn't show all 8 columns of shortcuts anymore, but only 7, even though there is more than enough space for 2 columns both left and right.

A recent update had a similar change and I had to change my right window from width 1528 to 1532.


Expected results:

Nothing in the new tab padding should have changed, my new tab should show all 8 columns of shortcuts.

I know this is a very minor issue, and a very unique situation, and is unlikely to be fixed. On the other hand
1) If this change was on purpose, why? There is no logical reason to not show a column because there is only room for 4 more. So to the person that decided to change the padding to 200+: please change it to e.g. 20 pixels.
2) If this is an accidental change, then maybe you should prevent it from happening more often (and also revert it), because soon people with 1080p monitors will be affected too.

Attached screenshots zoomed 100% with 7 rows (with obvious room for 4, maybe even 5, more colums). Again: yesterday it showed all 8 rows at 100% zoom.
Bug: In certain cases the results from Merino are not triggered even if the keyword matches the result
Status: NEW
Priority: --
Created: 2025-03-05 10:48:20+00:00
Resolved: 2025-03-05 17:30:48+00:00

**[Affected versions]:**
- Firefox Release 136.0 (Build ID: 20250225123537)
- Firefox Beta 137.0b7 (Build ID: 20250303103151)
- Nightly 138.0a1 (Build ID: 20250219215346)

**[Affected Platforms]:**
- Windows 11
- MacOS 14.7.1
- Linux Mint 20.1

**[Prerequisites]:**
- Have a Firefox 137 en-US build installed/extracted.
- Have the following prefs set:
 - browser.search.region = US
 - browser.urlbar.quicksuggest.dataCollection.enabled = true 
 - browser.urlbar.quicksuggest.rustEnabled = false

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
3. Click in the addressbar. 
4. Type a keyword that would trigger a result from merino (eg: amazon prime login).
5. Observe the Sponsored result.

**[Expected result]:**
- The sponsored result is constantly triggered when typing the keyword, while it's a match.

**[Actual result]:**
- The Sponsored result is not displayed in certain cases while typing the keyword, even if it matches a Merino result.

**[Notes]:**
- This issue is also reproducible with non-sponsored results.
- Attached is a screen recording of the issue.
Bug: Middle clicking the new tab button opens the tab in a different place to everywhere else.
Status: NEW
Priority: --
Created: 2025-03-05 12:03:53+00:00
Resolved: 2025-03-05 12:03:53+00:00

The logic used to decide where to open a new tab when middle-clicking the new tab button appears different to when clicking the new tab button or middle clicking the tab bar.

If I have a tab bar like this:
```
[tab 1][tab 2][tab 3][+]
```

When tab 2 is the currently selected tab, middle clicking the new tab button opens a new tab between tab 2 and tab 3. This is different to any other behaviour for opening a new tab (left clicking the new tab button, clicking file -> new tab, middle clicking the empty part of the tab bar) all of which open a new tab after tab 3.