av9ash/GitBugs huggingface dataset:
Bug: XSS attack via faveicon.ico
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-06-06 09:43:51+00:00
Resolved: 2024-06-13 09:55:26+00:00

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

Steps to reproduce:

I found an issue regarding the adservice.google.com cookie while investigating issues with google bug bounty, There seems to be 2 problematic IP addresses tied to this "google ad services" link i presented earlier:        142.251.111.155 and     142.251.111.154 by using whois on adservice.google.com, The problem with these addresses is they are insecure due to using http and not https, if you enter the ip addresses normally you will get redirected to the https, however if you enter http://142.251.111.154/155 <-- exactly the following errors come up: HTTPS-Only Mode: Not upgrading insecure request “http://www.google.com/images/errors/robot.png” because it is exempt.
robot.png
HTTPS-Only Mode: Not upgrading insecure request “http://142.251.111.154/favicon.ico” because it is exempt.
favicon.ico
HTTPS-Only Mode: Not upgrading insecure request “http://www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png” because it is exempt.

I am unsure why these ip addresses tied to adservice.google.com exist and from this it appears that this "adservice.google.com" is a major vulnerability and can cause a damaging https/certification weakness allowing anyone to intercept traffic and steal data.

This "adservice.google.com" appears on google.com when you inspect elementnd it will show the following:GET adservice.google.com file: ui and this was the link for it: https://adservice.google.com/adsid/google/ui (take caution with this as it may be compromised). if you go to the  favicon.ico that appears there you will see corrupted C programs embedded within the svs.mjs blue links


Actual results:

Google.com getting hacked, the program has been injected into google.com/my browser may have been affected.

result	
code	"error"
message_code	"missing_api_authentication"
message	"No X-API-KEY header was provided in the request" for getting the api for my current firefox.

and: <?xml version="1.0"?>
<!-- This Source Code Form is subject to the terms of the Mozilla Public
   - License, v. 2.0. If a copy of the MPL was not distributed with this file,
   - You can obtain one at http://mozilla.org/MPL/2.0/. -->

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml"
        xmlns:html="http://www.w3.org/1999/xhtml"
        role="document"
        id="preferences-root"> from: view-source:about:preferences#home


Expected results:

what should have happened is firefox should not be allowing their system code to be manipulated this way making user data vulnerable.
Bug: Fix empty strings assigned in Sidebar.ftl
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-06-06 10:22:20+00:00
Resolved: 2024-07-31 21:16:54+00:00

This came up in review of :mardak's patch in bug 1899827 and flod pointed out we shouldn't have empty strings assigned to fluent ID's. 

I admit I don't recall exactly why these were added in bug 1892429, and its curious given that we only pass the l10n IDs if they're defined [here](https://searchfox.org/mozilla-central/source/browser/components/sidebar/sidebar-main.mjs#206). So then why do we need the empty strings? Was this leftover from your original solution Jonathan?
Bug: Ghost shadow on feature callout arrow when flip=slide makes the arrow disappear (MacOS)
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-06-06 10:56:05+00:00
Resolved: 2024-06-27 15:00:16+00:00

When you move the window so that the callout would bleed off the screen's edge, it either flips or slides so it can stay on screen. When it slides, the arrow is configured to disappear, because sliding it over means the arrow would no longer be pointing to the right element. But when this happens on macOS, there's a spooky echo of the arrow's shadow because the `-moz-window-shadow` effect was apparently "locked in" and hiding the arrow does not re-render it. So you still get the same shadow as you had when the arrow was visible. We should do `-moz-window-shadow: none` to avoid this issue, and also because we're already applying a shadow anyway. So we're effectively doubling up on shadows on macOS.
Bug: The wallpaper feature highlight is displayed for 4 times instead of 3
Status: NEW
Priority: --
Created: 2024-06-06 14:23:20+00:00
Resolved: 2024-06-06 14:23:20+00:00

**[Affected versions]:**
- Firefox Nightly 128.0a1 - Build ID: 20240606092816

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

**[Prerequisites]:**
- Have the following prefs in the "about:config" page:
	- `browser.newtabpage.activity-stream.newtabWallpapers.enabled` set to `true`
	- `browser.newtabpage.activity-stream.newtabWallpapers.highlightEnabled` set to `true`
- Have no wallpaper set.
  
**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Open a New Tab and wait for ~3 seconds.
3. Repeat step 2 for two more times.
4. Open a New Tab and observe the behavior.

**[Expected result]:**
- The wallpaper feature highlight is NOT displayed.
    
**[Actual result]:**
- The wallpaper feature highlight is displayed.

**[Additional Notes]:**
- The wallpaper feature highlight is no longer displayed after is shown for the fourth time.
- Attached a screen recording of the issue.
Bug: Skylight - Fix infobar Looker dashboards and display correct CTR percents in tables
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-06-06 14:36:19+00:00
Resolved: 2024-06-26 14:54:33+00:00

Currently, we are hiding the CTR values for all InfoBar messages because they aren't being retrieved correctly. Proposed solution:

- Copy the existing [InfoBar dashboard](https://mozilla.cloud.looker.com/dashboards/1682?Messaging+System+Ping+Type=infobar&Submission+Date=30+days&Messaging+System+Message+Id=INFOBAR_LAUNCH_ON_LOGIN&Normalized+Channel=release&Normalized+OS=&Client+Info+App+Display+Version=&Normalized+Country+Code=&Experiment=&Experiment+Branch=) and update it so that `primary_rate` is the property we are grabbing for the CTR metrics 
- More investigation and fixing might need to be done to ensure we are getting the correct CTR values
Bug: Glean "weather_change_display" event  extra key "weather_display_mode" is wrong data type
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-06-06 15:57:18+00:00
Resolved: 2024-06-07 04:24:22+00:00

https://searchfox.org/mozilla-central/source/browser/components/newtab/metrics.yaml#281 This paramater should be "string" type, instead of "boolean"
Bug: New search config isn't sending the "search-with" ping to glean
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-06-06 15:59:32+00:00
Resolved: 2024-06-27 07:16:13+00:00

It appears that with the v2 search rollout, we are not sending the clickUrl to Admarketplace

https://searchfox.org/mozilla-central/source/browser/components/search/BrowserSearchTelemetry.sys.mjs#185
Bug: Autofill sometimes is activated when focusing the urlbar with persisted search terms
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-06-06 16:11:44+00:00
Resolved: 2025-01-23 08:45:15+00:00

When there's persisted search terms that are also a matchign string for autofill, focusing the urlbar sometimes activates autofill.

Steps to reproduce:
1. type "moz", it will autofill to moz[illa.org]
2. backspace the autofilled part, and confirm to load Google search for "moz"
3. ensure the urlbar is not focused
4. either left or right click on the urlbar to focus it

ER:
"moz" should be selected
AR:
"moz[illa.org]" is autofilled

This doesn't happen every time, but blurring and focusing again, or reloading the page, blurring and focusing again, makes it happen after less then 10 tries.

I got this regression range after a few tries, due to the intermittent nature of the issue:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=702d4a62e5d03a2b36b3a17645718208a30ddb08&tochange=45fc9bb4de9c9d7d5b9933977891a99d10e47d6e
Out of that, I think the most likely bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1815686 as it is modifying some condition around `allowAutofill`... Though it's also possible that was wallpapering lack of `allowAutofill` management in the persisted search terms case (should always be false if there's persisted search terms)
Bug: Firefox on Windows with mismatched system theme (dark mode OS, light mode FF) loads a new tab with wrong colors temporarily
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2024-06-06 16:54:04+00:00
Resolved: 2024-07-10 19:45:38+00:00

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

Steps to reproduce:

1. Start on dark mode (also have system in dark mode)
2. Switch to light mode


Actual results:

When loading Firefox will sometimes briefly appear in dark mode, and then transition to light mode


Expected results:

Firefox should load with the correct theme intially
Bug: Dragging a bookmark within the bookmarks tooblar makes other bookmarks bounce left and right
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-06-06 20:41:26+00:00
Resolved: 2024-06-20 14:43:16+00:00

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

Steps to reproduce:

1. Make sure you have the bookmarks toolbar items visible and populated.
2. Try to move a bookmark or folder from one location to another by dragging it. This won't reproduce for items inside a folder.


Actual results:

The other items move back and forth as you hover over them with the bookmark you try to move.


Expected results:

Mozregresion points to either Bug 1900783 or Bug 1900784. I'll mark 1900783 as the regressor.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e2739904da9469a32a83a90b534a860f5f427dd9&tochange=698a19071fd1cb07baa92f9c28d69a09e43e61ff
Bug: Green text on about:studies has low color contrast on the dark page appearance
Status: NEW
Priority: P3
Created: 2024-06-06 20:47:43+00:00
Resolved: 2024-06-21 14:56:46+00:00

On the `about:studies`, i.e. `about:studies?optin_slug=review-checker-v11-experiment&optin_branch=treatment-a` green text like an opt-in status `Active` or general success status `Opt-in was successful` on the dark theme (web appearance) have low color contrast of 3.82:1 while 4.5:1 or more is expected for the regular text per [WCAG](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html).

Accessibility severity is set to `access-S3` because the same shade of green provides sufficient color contrast on the light web appearance
Bug: New Tab Weather Widget awkwardly overlaps Firefox logo, if your window is small (~500px by 690px)
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2024-06-06 23:08:02+00:00
Resolved: 2024-07-17 20:10:48+00:00

STR:
1. Open a new tab.
2. Make your Firefox viewport skinny (e.g. 500-600px wide) and short (**less than 700px tall** -- this is important since it shifts the Firefox logo upwards)

ACTUAL RESULTS:
The New Tab Weather Widget at the top left corner overlaps the Firefox logo that's centered at the top of the new-tab page -- the widget's 3-dot-menu, subtle vertical bar, and city name / temperature literally draw on top of the Firefox logo, such that they become kinda unreadable and look glitchy.

EXPECTED RESULTS:
Design should be responsive to avoid this sort of overlap; at these viewport sizes, the widget should disappear, or move, or change its layout, to avoid this overlap.
Bug: Address bar autocompletion panel (and its contents) jiggle up and down when I press Ctrl, as "Switch to tab" buttons get converted to URLs
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-06-06 23:55:58+00:00
Resolved: 2024-12-19 19:48:47+00:00

STR:
1. Have several tabs open with "todo" in the title (the exact string doesn't matter, that's just what I happened to use to trigger it). e.g. these ones:
https://bugzilla.mozilla.org/show_bug.cgi?id=1846560
https://bugzilla.mozilla.org/show_bug.cgi?id=1874079

2. Focus your address bar and type "todo"
3. Press Ctrl, and then release Ctrl (to toggle between "Switch to tab" and URLs) 

EXPECTED RESULTS:
No change in heights/vertical-positioning.

ACTUAL RESULTS:
- Everything after the first switch-to-tab suggestion moves up a bit when I press ctrl (and the buttons disappear)
- This means the bottom border of the whole autosuggestion panel itself moves up a little bit
- It looks like the autocomplete suggestions get very-slightly-shorter when I press Ctrl, I think?
Bug: Firefox is showing as installed twice
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-06 23:58:13+00:00
Resolved: 2024-06-07 11:00:42+00:00

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

Steps to reproduce:

After latest update I know have 2 Firefox installed, 1 es version 126.0 and the other one is 126.0.1


Actual results:

Firefox is now showing twice under programs in add/remove programs


Expected results:

It should have updated the existing version of it. I assume this happens cause the original one was installed on a D drive instead of a C drive.
Bug: Translations panel not reported by screen reader when it pops up
Status: NEW
Priority: --
Created: 2024-06-07 04:23:35+00:00
Resolved: 2024-06-21 14:21:08+00:00

STR (with the NVDA screen reader):

1. Open a page that causes the translation panel to pop up; e.g. https://de.wikipedia.org/
    - I don't quite understand what the rules are as to when this pops up vs when you have to press the toolbar button. I get the impression it has something to do with a page you haven't already loaded before in this session, but I'm not sure.
2. Listen to what the screen reader reports for a few seconds.
    - Expected: The screen reader should report the content of the translation panel within a few seconds.
    - Actual: The screen reader just reads the document. The fact that the translations panel popped up is never reported.

Impact: A screen reader user has no idea that this panel popped up.

I'm marking this as an s3 because this panel doesn't always pop up anyway and there is a workaround: open it from the toolbar as if it never popped up. Of course, this makes this far less discoverable to a screen reader user and it could arguably be an s2 because that equivalent discoverability is inaccessible.

The reason for this is that the panel has a role of alertdialog instead of alert. alertdialogs are only read if focus moves inside them, whereas alerts indicate important content that might not have focus. alertdialog might have been fine if this panel got focus when it pops up, but it doesn't. Note that our other doorhangers have an implicit role of alert.
Bug: Translations: Extraneous tab stop between Settings and Download all buttons
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-06-07 04:34:59+00:00
Resolved: 2024-07-12 12:28:47+00:00

(I wasn't sure whether to file this in the Translations component or the Settings component. Please move if necessary.)

STR (with the NVDA screen reader):

1. Open Firefox Settings.
2. Focus the Settings button for Translations.
3. Press tab.
    - Expected: Focus should move to the Download All button.
    - Actual: Focus moves to a div with id translations-manage-install-list and NVDA reads *the entire content of this section*: "Download languages for offline translation Download all button alt+shift+d Remove all alt+shift+e Bulgarian Download button ..."

This bug will go away once bug 1836304 is implemented. Until then, it's rather ugly. If bug 1836304 isn't likely to happen any time soon, I think this div needs tabindex="-1" so it doesn't get included in the tab order.
Bug: YouTube shortcut key bug
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-06-07 05:12:12+00:00
Resolved: 2025-01-06 12:16:54+00:00

Steps to reproduce:

I always using shortcut key in YouTube such as f (Toggle full screen), i (Toggle mini-player), t (Toggle theater mode), m (Mute), j (Rewind 10 seconds), k (Toggle play/pause), and l (Fast forward 10 seconds).


Actual results:

If I use the one of the shortcut key such as f key, first time is okay, but if I use it second time, it will pop out the search text bar, sometimes it will stuck there at the default mode of the video screen mode.


Expected results:

If I use the f key, no matter how many times I use that shortcut key or other shortcut key, it can function properly. I tried on another browser, only Firefox has this kind of problem
Bug: Firefox fails to relaunch after closing the browser when “Scan in progress” dialog is shown
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-06-07 07:12:05+00:00
Resolved: 2024-09-11 11:08:57+00:00

**Found in**
* 128.0a1 (2024-06-06)

**Affected versions**
* 128.0a1 (2024-06-06)

**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view 
* Create a distribution folder inside the Firefox folder and paste the policies-1.json to it and then rename it to policies.json
* Run the DLP agent in CMD using: .\content_analysis_sdk_agent.exe --user --toblock=.\d{3}-?\d{2}-?\d{4}. --towarn=.warn. --delays=10

**Tested platforms**
* Affected platforms: Windows 10/11
* Unaffected platforms:Ubuntu 22.04, macOS 12.6.6

**Steps to reproduce**
1. Navigate to https://support.mozilla.org/ 
2. Open up a document in an external program (for example Notepad) and type “ok text” into it and copy it
3. Return to Firefox and paste the “ok text” into the search bar in the middle of the page
4. While the scan is still in progress, quit the browser without interacting with the dialog “Scan in progress” dialog
5. Open Firefox again and observe the behavior

**Expected result**
*  Firefox is successfully launched

**Actual result**
* Firefox does not launch


**Regression range**
* This is not a regression as this is a new feature

**Additional notes**
* After quitting Firefox while the message is displayed, it remains active as a background process for 1-2 minutes (can be checked in Task Manager)
* Not reproducing if attempting to relaunch Firefox after it is no longer running in the background
* Also, after managing to launch the browser, it seems that a silent crash occurred due to the performed actions (go to about:crashes):
– https://crash-stats.mozilla.org/report/index/b9d06641-f135-4103-9a1f-c70270240607 
– https://crash-stats.mozilla.org/report/index/e260ba0c-d9b5-4303-91c1-e56a30240607 
* This was fixed for the blocked/warn dialogs in Bug 1898718 / Bug 1899703 
* Not reproducing for the upload operation
Bug: The "Personalize" icon is barely visible when displayed on the "Search Bar and an opposite color wallpaper to the theme is set
Status: NEW
Priority: --
Created: 2024-06-07 13:27:01+00:00
Resolved: 2024-06-07 13:27:01+00:00

**[Affected versions]:**
- Firefox Nightly 128.0a1 - Build ID: 20240606154042

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

**[Prerequisites]:**
- Have the following prefs in the "about:config" page:
	- `browser.newtabpage.activity-stream.newtabWallpapers.enabled` set to `true`
	- `browser.newtabpage.activity-stream.newtabWallpapers.v2.enabled` set to `true`
- Have the "Dark" browser theme set from the "Themes" section of the "about:addons" page.
  
**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Open a New Tab and click the "Personalize" button from the top-right part of the page.
3. Select a light color theme.
4. Scroll down the page until the in-content "Search Bar" is stuck on the top of the screen.
5. Observe the "Personalize" button.

**[Expected result]:**
- The "Personalize" button is fully visible.
    
**[Actual result]:**
- The "Personalize" button is barely visible.

**[Additional Notes]:**
- The issue is not reproducible if a wallpaper with the same color as the browser theme is set.
- The issue is not reproducible if no wallpaper is set.
- The issue is not reproducible if the "Personalize" button is not displayed on the "Search Bar".
- Attached a screen recording of the issue.
Bug: browser.search.widget.inNavBar is not always reflecting search bar status
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2024-06-07 13:33:54+00:00
Resolved: 2024-08-19 20:15:08+00:00

**Found in**
* 128.0a1

**Affected versions**
* 128.0a1 (2024-06-07)
* 127.0 RC2
* 126.0.1
* 115.11.0esr   

**Tested platforms**
* Affected platforms: Ubuntu 22.04, Windows 10, Mac 13

**Steps to reproduce**
1. Customize Toolbar.
2. Drag and drop search bar to the overflow menu or bookmarks toolbar or anywhere else is possible but the navigation toolbar.
3. Verify the value of *browser.search.widget.inNavBar*.

**Expected result**
* *browser.search.widget.inNavBar* value is true

**Actual result**
* *browser.search.widget.inNavBar* value remains false

**Regression range**
* Not a recent regression.

**Notes**
* Most likely *browser.search.widget.lastUsed* and *browser.search.widget.removeAfterDaysUnused* will not function properly in this case
* Given that searchbar option is not exposed anymore in the preferences, maybe *browser.search.widget.inNavBar* should be removed
Bug: Jpeg2000 image not displayed
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-06-07 15:21:00+00:00
Resolved: 2024-06-19 21:13:11+00:00

The image is too large and at some point `malloc` is failing:
https://github.com/mozilla/pdf.js.openjpeg/blob/e107b31a90a1c6bdc0966d4f73187d730b60624d/src/decoder.c#L213
Bug: firefox doesnt show the pics in one web, this web has a Photonic plugin of wordpress, in chrome is ok
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-06-07 16:26:27+00:00
Resolved: 2024-07-25 13:20:08+00:00

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

Steps to reproduce:

firefox doesnt show the pics in one web, this web has a Photonic plugin of wordpress, in chrome is ok


Actual results:

Firefox shows the pics from de hosting web, but It doesnt show pics with redirections from Photonic plugin of wordpress.  In chrome is ok.


Expected results:

firexfox should show the pics on the web page searching
Bug: Skylight - Improve performance for displaying CTR values
Status: RESOLVED
Priority: P1
Resolution: WORKSFORME
Created: 2024-06-07 17:01:10+00:00
Resolved: 2024-07-17 20:42:34+00:00

Currently, it takes ~20 seconds for Skylight to finish loading and displaying all the CTR values. We want to improve this performance to be more reasonable. See this [spike document](https://github.com/mozilla/skylight/pull/214/files#diff-d305ec138192dcb7706226becfd90a1d8e20a99e22ad63cbc1e76f028343e251) for some potential ideas on where to start. Particularly, follow this [article](https://www.googlecloudcommunity.com/gc/Technical-Tips-Tricks/Looker-API-Performance-Best-Practices/ta-p/591327) for some tips.
Bug: Tab has no focus ring when a LWT is installed
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-06-07 19:07:17+00:00
Resolved: 2024-07-05 09:13:05+00:00

With a LWT installed there is no focus ring shown when a tab is focused.

STR
1. Install a LWT (Light/Dark/Alpenglow all reproduce)
2. Press F6, Shift+Tab to the New Tab button
3. Press Shift+Tab again
4. Press Left/Right to change tabs

Expected results: The tab has a focus ring
Actual results: No focus ring is shown
Bug: The main navbar toolbar puts buttons into the overflow menu when it shouldn't
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-06-07 19:58:07+00:00
Resolved: 2024-07-30 12:55:29+00:00

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

Steps to reproduce:

It is random, but most often I occurs where reading the New York Times. 
From the front page of New York Times, I use the middle button to select the pages that I want to read this day, normally more then 20. As I go through the pages, at random most of the buttons on the tool bar will disappear. Restarting Firefox fixes the problem


Actual results:

The buttons on the toolbar disappear


Expected results:

The buttons should not disappear.