av9ash/GitBugs huggingface dataset:
Bug: Perma browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js | Check the scheme value after blur - "" == "https://" - when Gecko 129 merges to beta on 2024-07-08
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-06-20 12:44:51+00:00
Resolved: 2024-07-09 13:44:35+00:00

[Central-as-beta-simulation](https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&selectedTaskRun=ei7M0xAJTE-wOCBo3-tspg.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cusercancel&revision=d79f257d7d92310506c4b5e05d38bc2434dde24f&test_paths=browser%2Fcomponents%2Furlbar%2Ftests%2Fbrowser%2F)

[How to run these simulations](https://wiki.mozilla.org/Sheriffing/How_To/Beta_simulations#TRUNK_AS_EARLY_BETA)

[Failure log](https://treeherder.mozilla.org/logviewer?job_id=463280772&repo=try)

```
[task 2024-06-20T11:28:21.674Z] 11:28:21     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js | Check the scheme box visibility - "hidden" == "hidden" - 
[task 2024-06-20T11:28:21.674Z] 11:28:21     INFO - Buffered messages finished
[task 2024-06-20T11:28:21.675Z] 11:28:21     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js | Check the scheme value after blur - "" == "https://" - 
[task 2024-06-20T11:28:21.675Z] 11:28:21     INFO - Stack trace:
[task 2024-06-20T11:28:21.675Z] 11:28:21     INFO - chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js:testVal:60
[task 2024-06-20T11:28:21.675Z] 11:28:21     INFO - chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js:null:120
[task 2024-06-20T11:28:21.675Z] 11:28:21     INFO - chrome://mochikit/content/browser-test.js:handleTask:1145
[task 2024-06-20T11:28:21.676Z] 11:28:21     INFO - chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1217
[task 2024-06-20T11:28:21.676Z] 11:28:21     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1358
[task 2024-06-20T11:28:21.676Z] 11:28:21     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:1134
[task 2024-06-20T11:28:21.676Z] 11:28:21     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058
[task 2024-06-20T11:28:21.676Z] 11:28:21     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_UrlbarInput_overflow.js | Check The input field overflow - true == true - 
```
Bug: Add additional allowed characters to search-config-icons filter expression pattern
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-06-20 14:31:39+00:00
Resolved: 2024-07-08 07:20:51+00:00

Currently, characters like <>()&| are not allowed in the search-config-icons schema's filter expression pattern. This rejects valid expressions such as "env.version|versionCompare(\"124.0a1\")>=0".
Bug: Update intro language on settings experimental page
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-06-20 15:22:24+00:00
Resolved: 2024-06-25 09:40:27+00:00

The "caution" icon and duplicate string ("Changing advanced configuration settings can impact Firefox performance or security." appears twice) looks a bit off.

We should update this per UX/content design requirements to be a bit more friendly.
Bug: SelectTranslationsPanel does not report the to-language-changed event to telemetry if both languages are changed prior to retranslation
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-06-20 16:46:18+00:00
Resolved: 2024-06-26 14:09:57+00:00

### Description

There is an edge case in the Select Translations Panel in which, using keyboard navigation, the user can change both the from-language and the to-language before triggering re-translation. 

When this happens, currently, only the from-language change is reported to telemetry. We should fix this so that both language-change events are reported to telemetry. 

---

### Steps to reproduce


> **Note**: This is only reproducible using keyboard navigation on Windows and Linux, because those two operating systems allow you to change the from-language and to-language directly with the keyboard _without_ opening the dropdown menu list. When the language is changed directly, the panel waits for the `Enter` key to be pressed, or for the `<textarea>` element to receive focus before translating. However on macOS, the keyboard navigation events _always_ opens the menu-list dropdown, in which case selecting a new language will trigger a translation when the dropdown closes. 

* Ensure that the `toolkit.telemetry.translations.logLevel` pref is set to `Debug`.
* Open the Browser Console and filter the output on `onChange`. 
* Navigate to a translatable web page, e.g. https://es.wikipedia.org
* Select some text, right click, and open the Select Translations Panel by clicking the "Translate selection...." item.
* Press `Tab` until the focus is on the from-menu list.
* Use the `Up`/`Down` arrow keys to change the language directly (without triggering a translation yet).
* Press `Tab` once to shift the focus to the to-menu list.
* Use the `Up`/`Down`  arrow keys to change the language directly (without triggering a translation yet). 
* Trigger a translation by pressing `Enter` or continuing to use `Tab` to shift the focus to the textarea. 

**Expected Behavior**
 * Both the `onChangeFromLanguage` and `onChangeToLanguage` events should be logged to the browser console.

**Actual Behavior**
* Only the `onChangeFromLanguage` event is logged to the browser console.

---

### Tests to implement

* Implement more thorough tests that change the from-language and to-language menus in all possible ways, both independently and together, to ensure that only the relevant telemetry events are fired in all cases.
Bug: Remove ghost shadow on feature callout on MacOS
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-06-20 16:52:25+00:00
Resolved: 2024-07-02 17:07:12+00:00

Follow up to [1900984](https://bugzilla.mozilla.org/show_bug.cgi?id=1900984), which fixes the ghost shadow on the arrow icon but we also need the entire callout to have `moz-window-shadow` set to `none` so the shadows are consistent.
Bug: On startup, "Firefox View" only populates "Open Tabs" in 1 window.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-06-20 18:14:07+00:00
Resolved: 2024-06-27 18:43:59+00:00

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

Steps to reproduce:

Firefox 127, Win 10, Acer E5-575 laptop i3-7100u GPU i620 24GB ram.
Open Firefox (set to reopen previous session windows and tabs [2000 tabs in 4-6 windows]).


Actual results:

"Open Tabs" section of "Firefox View" is only populated in 1 of the windows, and is left blank in all others.


Expected results:

"Open Tabs" should have populated in all windows, otherwise I have to go hunting for the window that is populated. Once I find that window and land on that dialog (Firefox View-Open Tabs) the other windows immediately populate, and from that point on works as expected.

Firefox View is immensely useful, and is my main navigational tool for my admittedly bloated tab count. This bug detracts from an otherwise brilliant feature . . .
Bug: FF 127 screenshot tool doesn't handle touchscreen taps
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2024-06-20 19:30:56+00:00
Resolved: 2025-01-02 19:26:26+00:00

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

Steps to reproduce:

I went to take a screenshot of a portion off a webpage.  I knew a single tap on my touchscreen would select the desired area.  In previous versions of FF, this worked nicely.  But it seems someone reinvented the wheel.

1. On a webpage, open the tool.
2. Tap any edit box that you want to pretend has contents you want to make an image of.


Actual results:

I see the tool blink.  It doesn't actually select anything.


Expected results:

If you tap rather than click, the tool should act like you clicked the mouse.
Bug: Enable about:messagepreview hint for release builds
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-06-20 20:04:19+00:00
Resolved: 2024-06-23 09:45:06+00:00

Currently there's a hint that will show up (on Nightly builds) in about:messagepreview if someone tries to paste a message with devtools preffed off. Now that it's being used more broadly we should enable the hint for all builds.
Bug: Close duplicate tab confirmation message only appears if 2 or more tabs are closed
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-06-20 20:29:54+00:00
Resolved: 2024-07-12 11:23:14+00:00

The pop-up confirmation message appears for when a user uses the "Close all duplicate tabs" action for the first time in the tab overview menu. The message should appear the first time a user closes 1 or more duplicate tabs

Expected:

User clicks on "Close all duplicate tabs" in the Tab overflow menu

A one time pop-up confirmation appears the first time a user closes 1 or more duplicate tabs

Actual

Pop-up only appears when it closes 2 or more tabs.
Bug: Cannot delete search suggestions from history
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-21 00:14:43+00:00
Resolved: 2024-06-21 06:57:42+00:00

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

Steps to reproduce:

1. Customize the toolbar and add the separate Search bar.
2. Search for a term, such as "firefox".
3. Click on the search bar to reveal the search history. See "firefox" with a clock icon indicating it comes from history.
4. Select the "firefox" history item, either with down arrow or right-click.
5. Press delete or shift-delete to delete the search item.


Actual results:

The search item appears to have been deleted, but as soon as you bring up the search suggestions it returns.


Expected results:

The search item should be removed and not show up again.

This is a regression from 126 to 127. I ran mozregression and got the following results to track down the breaking change: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8817b19391096abc4d12af946fb59f2867e3d087&tochange=33c9e2ecd2740e10fb165708ed97aa7a66c1cc44
Bug: Save as file box random open on websites (unexpected downloads being started)
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-06-21 02:46:32+00:00
Resolved: 2024-08-02 22:52:30+00:00

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

Steps to reproduce:

This bug happens at random. Sometimes it is triggered by the back button in Firefox, sometimes its something on the website that triggers this bug. They all have that it common that save as box opens with a random file name to save. I am not able to reproduce this bug if it happens once in a open session of Firefox. This started with Firefox version 127.0.1. It was not in earlier version (126). This bug might vanish in next version of Firefox.


Actual results:

The save file as box randomly opens on websites even if I don't press the save file as option. That I notice.


Expected results:

The save file as box should not have opened when the back button is pressed of something on a website is pressed.
Bug: PDF content has a shifting effect during zoom operations
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-06-21 08:41:10+00:00
Resolved: 2024-07-11 19:25:13+00:00

**Found in**
* 128.0b5

**Affected versions**
* 129.0a1 (2024-06-20)
* 128.0b5
* 127.0.1
* 115.12.0esr

**Tested platforms**
* Affected platforms: Windows 11, Ubuntu 22.04, MacOS 13 / 14
* Unaffected platforms: none

**Steps to reproduce**
1. Launch Firefox and access the pdf: http://foersom.com/net/HowTo/data/OoPdfFormExample.pdf / https://pdf.ninja/interactiveform_enabled.pdf 
2. Zoom in and out the page several times
3. Observe the content of the PDF while zooming in / out

**Expected result**
* The content of the PDF has no shifting / moving effect while zooming in and out

**Actual result**
* The content of the PDF has a shifting / moving effect while zooming in and out

**Regression range**
* Last good build: 2023-01-03
* First bad build: 2023-01-04
* Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2288a4992fac2e0ecb886f1f9bfcdbe39cc18393&tochange=9d96d2c96d8fe1d9365fdaee30d8fda048c48aa1 
* Potentially regressed by: I suspect that bug 1807983 is a potential regressor, but I am uncertain and Mozregression is unable to bisect more data. Hope this helps! 

**Additional notes**
* See the attached video 
* The shifting effect is more visible for the selected checkboxes 
* Not reproducing on Chrome browser
Bug: [macOS] Tab hover preview is misplaced or missing when dragging the window to an external monitor
Status: NEW
Priority: P3
Created: 2024-06-21 11:45:55+00:00
Resolved: 2024-08-06 19:25:51+00:00

**Found in**
* 128.0b5

**Affected versions**
* 129.0a1 (2024-06-20)
* 128.0b5

**Tested platforms**
* Affected platforms: MacOS 13/14
* Unaffected platforms: Windows 11

**Preconditions**
* ‘browser.tabs.hoverPreview.enabled’ set to ‘true’ 
* Have at least one external monitor connected and configured to be positioned above the main display

**Steps to reproduce**
1. Open a few tabs
2. Drag the browser window upwards to the external monitor, until the window appears at the bottom edge of the external monitor
3. Hover on each tab

**Expected result**
* Tab hover preview is correctly displayed and positioned

**Actual result**
* Tab hover preview is misplaced and truncated 

**Regression range**
* Not a regression since this is reproducible on the old Nightly build from 2024-01-14 where this feature officially landed

**Additional notes**
* See the attached ss
* Also, the tab hover preview is not displayed when other display arrangements are configured (side by side, below) and the window is dragged to the edge of the second screen. To reproduce the issue in a side by side monitor arrangement, position the window between monitors so that only 3-7 tabs are visible
* Not reproducing when dragging the window above the edge of the external monitor
* Not reproducing on Chrome browser
* I am unable to test this on Ubuntu
Bug: About:addons has missing content in the tab preview if scrolling in the page
Status: NEW
Priority: P3
Created: 2024-06-21 13:14:06+00:00
Resolved: 2024-06-24 16:46:50+00:00

**Found in**
* Latest Nightly 128.0b5

**Affected versions**
* Latest nightly 129.0a1
* Firefox 128.0b5 (if pref is turned on)

**Tested platforms**
* Affected platforms: macOS 13, Windows 11, Ubuntu 22.04
* Unaffected platforms: none

**Preconditions**
* Have `browser.tabs.hoverPreview.enabled` set to `true`

**Steps to reproduce**
1. Open about:addons page focus another tab
2. Hover over the about:addons tab
3. Scroll down the page in about:addons
4. Focus another tab and hover over the about:addons tab

**Expected result**
* The content from about:addons tab preview is correctly displayed

**Actual result**
* Content is missing from the about:addons preview image and also is not updated to show the in view content.

**Regression range**
* I was only able to reproduce this after bug 1879089 was fixed since until that fix the content from the preview would not update only after a revisit of the page but the scroll position would be lost in that case. So probably the root cause of this is not in bug 1879089 but for now I would mark it as the regressor until further investigation from engineering.

**Additional notes**
* We are not sure if other pages might be impacted by this at this time, we did not see this happen on the random websites we tried.
Bug: "Try a splash of color" modal breaks automated flows by unexpectedly making a new tab useless until you dismiss it
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-21 17:01:21+00:00
Resolved: 2024-08-06 17:58:06+00:00

Steps to reproduce:

The automated test system I maintain (Fedora openQA) tried to open a new tab in Firefox and use it normally.


Actual results:

An annoying "Try a splash of color" modal appeared, rendering the tab useless and breaking the test.


Expected results:

This should not have happened. If you're going to ambush people opening new tabs with useless self-promotion, please at least do it in such a way that it can be ignored and the tab still works for normal purposes. Or, alternatively *at least* make it so that all of this crap I have to maintain to avoid other stuff like this:

printf '{"policies": {"DisableFirefoxStudies": true, "OfferToSaveLogins": false, "OverrideFirstRunPage": "", "OverridePostUpdatePage": ""}}' > $(rpm --eval %_libdir)/firefox/distribution/policies.json
printf "// required comment\npref('general.config.filename', 'openqa-overrides.cfg');\npref('general.config.obscure_value', 0);\n" > $(rpm --eval %_libdir)/firefox/browser/defaults/preferences/openqa-overrides.js
printf "// required comment\npref('browser.urlbar.quicksuggest.shouldShowOnboardingDialog', false);\npref('privacy.restrict3rdpartystorage.rollout.enabledByDefault', false);\n" > $(rpm --eval %_libdir)/firefox/openqa-overrides.cfg

*also* suppresses this. It's very annoying keeping up with all this stuff.
Bug: User trend: Firefox download failures
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-06-21 17:16:58+00:00
Resolved: 2024-07-18 12:35:38+00:00

Multiple SUMO forum threads reporting download failures with files and extensions. Recent examples:
https://support.mozilla.org/en-US/questions/1449267
https://support.mozilla.org/en-US/questions/1449372
https://support.mozilla.org/en-US/questions/1449469
https://support.mozilla.org/en-US/questions/1449512
https://support.mozilla.org/en-US/questions/1449517
https://support.mozilla.org/en-US/questions/1449519
https://support.mozilla.org/en-US/questions/1449749
Bug: Onboarding "Skip this step" button slides outside the bounds of its card when you click it (as it fades out of view)
Status: NEW
Priority: P3
Created: 2024-06-21 21:29:08+00:00
Resolved: 2024-06-24 17:48:56+00:00

STR:
1. Visit `about:welcome`
2. Click "skip this step" and watch very carefully to see what happens to the "skip this step" button.

ACTUAL RESULTS:
The button drifts off the bottom of the card that it was on, drawing outside of the white card-area (drawing over the progress-bar strip at the bottom).

EXPECTED RESULTS:
It feels like the card is meant to be a physical container for that button; as the button disappears, it still shouldn't escape the bounds of the card.
Bug: The header of screenshot preview is hidden behind the responsive design mode header bar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-22 06:48:43+00:00
Resolved: 2024-06-24 14:41:22+00:00

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

Steps to reproduce:

1. Enable "Responsive Design Mode" (command + option + M)
2. Take a screenshot (command + shift + S)
3. Click "Save visible" or "Save full page"


Actual results:

The header of screenshot preview is hidden behind the responsive design mode header bar.


Expected results:

The screenshot preview should be displayed at the forefront.
Bug: about:newtab becomes scrollable after enabling a background
Status: NEW
Priority: P3
Created: 2024-06-22 11:57:51+00:00
Resolved: 2024-07-01 16:48:50+00:00

After changing from no-background to one of the built-in backgrounds on about:newtab, the page suddenly becomes scrollable. I think this is related to the copyright information (e.g.  "Photo by Will Rust on Unsplash") at the bottom of the page? Scrolling down doesn't show any new content, just moves everything up a bit.
Bug: When automatically creating a screenshot file name using native tools, the file name became severely truncated
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-22 13:46:19+00:00
Resolved: 2024-06-24 14:39:17+00:00

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

Steps to reproduce:

For example, let's go to the page
https://send.monobank.ua/jar/7UsDUH6np1
and click on scissors or ctrl+shift+s
select the area and click save to file


Actual results:

Starting with Firefox version 127 or a little earlier, the automatically generated file name began to be truncated. In the example given, even the time is not included in the file name. Previously, there was a file name like "Screenshot 2024-04-07 at 18-07-33 Careless transfer of costs.png", now "Screenshot 2024-06-22 a[...].png"


Expected results:

Previously, there was a file name like "Screenshot 2024-04-07 at 18-07-33 Careless transfer of costs.png", now "Screenshot 2024-06-22 a[...].png"
The problem with time cutting does not appear on all sites. For example on
https://www.flightradar24.com/52.20,23.37/6
file name is suggested
"Screenshot 2024-06-22 at 16-43-50 Flightradar24 Live Fl[...].png"
which is already more acceptable.
Bug: How dare Mozilla use the "Not Now" anti-pattern instead of "No"
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-06-22 20:23:59+00:00
Resolved: 2024-06-24 15:53:25+00:00

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

Steps to reproduce:

Windows 10 Home
Firefox 127.0, 64 bit

Started Firefox. Opened a new window and new tab.


Actual results:

A bar appeared across the top of the screen asking if I wanted to start Firefox on boot. Annoying.

It gave what should have been a "yes/no" prompt, but was instead the abusive, disrespectful "Not Now" / nudge to say "Yes" prompt. Unacceptable from boyfriends, ubiquitous from tech corporations.


Expected results:

A clear "Yes" or "No" when pestering a user with a new feature. Both buttons given equal weight by color.

I have loyally stayed with Firefox throughout its many years losing ground in the browser wars, stood up for it against social pressure saying Chrome is better, because to me, privacy and respect for users was more important than Chrome's speed, sandboxing, or marketing.

For-profit corporations are the ones who use inviting blue buttons to nudge users into signing up for things they don't necessarily want and who disrespect our ability to consent by forcing us to click "not now", when I want to say "NO! NEVER!"

Even Gmail let me say "No, Thanks" when pestering me with an unwanted "feature".

Is this what it has come to? Does Firefox need to adopt hated anti-user nudge patterns to survive dipping below the critical threshold where it will death spiral in market share? 

At the very least, the only viable open-source browser should respect user's ability to consent. "No" means no!
Bug: MLB box scores hard to read
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-06-23 03:21:58+00:00
Resolved: 2024-06-27 06:41:52+00:00

Steps to reproduce:

From MLB.com, hover over a game a load a Wrap or Gameday

Example: https://www.mlb.com/gameday/angels-vs-dodgers/2024/06/22/746132/live


Actual results:

Dark text on a dark background are hard to read.


Expected results:

Should be white text on a dark background