av9ash/GitBugs huggingface dataset:
Bug: Firefox has new-tab "Top Sites" tile for Twitter (now X), using old name/branding/domain
Status: NEW
Priority: P3
Created: 2024-06-13 17:37:07+00:00
Resolved: 2025-02-25 08:21:15+00:00

STR:
1. Start Firefox (Nightly) with a fresh profile.
2. Open a new tab.
3. Look at the tiles at the top of the new tab.

ACTUAL RESULTS:
The rightmost tile for me is Twitter, with the bird logo, linked to https://twitter.com/

EXPECTED RESULTS:
We should be linking using their up-to-date name, logo, and URL -- namely, the name "X", the fancy X-logo shown at e.g. https://developer.x.com/en, and the link URL should be https://x.com/ (which twitter.com auto-redirects to, as of last month per e.g. [this article in The Verge](https://www.theverge.com/2024/5/17/23829098/twitter-x-com-url-links-switch)
Bug: Skylight - Fix treamtment-b dashboard lossage
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-06-13 20:04:25+00:00
Resolved: 2024-06-18 18:55:18+00:00

The Discovery of Search SAP Existing EN and Discovery of Search SAP Early Day EN experiments have broken dashboard links for their treatment-b branches. The branch ids for those broken links have `:treatment-a` at the end, despite them being treatment-b branches, causing the links to break.
Bug: SelectTranslationsPanel top and bottom margins are too small
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-06-13 20:36:47+00:00
Resolved: 2024-06-17 15:21:23+00:00

### Description

Bug 1901314 removed the HTML element `id` [select-translations-panel-a11y-document-wrapper](https://searchfox.org/mozilla-central/rev/4c8627a76e2e0a9b49c2b673424da478e08715ad/browser/themes/shared/translations/panel.css#120-122) which was actually being used for a cSS rule. 

I didn't realize it during review, but we should add that id back in. 

---

### Steps to implement

* Reintroduce the id to the markup.

---

### Tests to implement

* This is a visual-only change. No automated testing needed.
Bug: Missing status checks in WriteBitmap()
Status: ASSIGNED
Priority: P3
Created: 2024-06-13 22:04:43+00:00
Resolved: 2025-01-20 08:52:57+00:00

`WriteBitmap()` (`browser/components/shell/nsWindowsShellService.cpp`) fails to check the status of `nsIOutputStream::Write()`. This means that if `Write()` fails, `WriteBitmap()` writes a malformed bitmap file to disk without detecting that fact. These files are used by `nsWindowsShellService::SetDesktopBackground()` to implement the "Set image as desktop background" context menu item. Thus, any exploit would have to involve some defect in Windows.

The bug that really matters is on line 473: if `Write()` writes the first row successfully (thus setting `written` to `bytesPerRow`), any combination of the following rows can fail without changing the value of `written`, thus spuriously causing the function to conclude that it successfully wrote the file.

You can verify that this is so by using a debugger to trace a `Write()` call down to where `_PR_MD_WRITE()` calls the Windows API `WriteFile()`, then manually skipping that call and setting `rv` == `0` (as WriteFile() does on failure), then tracing back out to `WriteBitmap()`.

Code from `FIREFOX_126_0_RELEASE`:

```
    406: static nsresult WriteBitmap(nsIFile* aFile, imgIContainer* aImage) {
    407:   nsresult rv;
    460:   // write the bitmap headers and rgb pixel data to the file
    461:   rv = NS_ERROR_FAILURE;
    462:   if (stream) {
    463:     uint32_t written;
    464:     stream->Write((const char*)&bf, sizeof(BITMAPFILEHEADER), &written);
    465:     if (written == sizeof(BITMAPFILEHEADER)) {
    466:       stream->Write((const char*)&bmi, sizeof(BITMAPINFOHEADER), &written);
    467:       if (written == sizeof(BITMAPINFOHEADER)) {
    468:         // write out the image data backwards because the desktop won't
    469:         // show bitmaps with negative heights for top-to-bottom
    470:         uint32_t i = map.mStride * height;
    471:         do {
    472:           i -= map.mStride;
    473:           stream->Write(((const char*)map.mData) + i, bytesPerRow, &written);
    474:           if (written == bytesPerRow) {
    475:             rv = NS_OK;
    476:           } else {
    477:             rv = NS_ERROR_FAILURE;
    478:             break;
    479:           }
    480:         } while (i != 0);
    481:       }
    482:     }
    483: 
    484:     stream->Close();
    485:   }
    ...
    489:   return rv;
    490: }
```
There is also a similar bug in `WinUtils::WriteBitmap(nsIFile* , SourceSurface* )` (`widget/windows/WinUtils.cpp`) but searchfox says that only `WinUtils::WriteBitmap(nsIFile*, imgIContainer*)` calls that, and that nothing calls `WinUtils::WriteBitmap(nsIFile*, imgIContainer*)`.
Bug: Address Bar still shows search engine suggestions
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-06-13 23:26:36+00:00
Resolved: 2024-06-14 08:49:18+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 updated the Address Bar suggested components to only include Browsing History and Bookmarks


Actual results:

When starting to type in the address bar, I see the suggested search engines at the bottom of the address bar pop out


Expected results:

I shouldn't see suggested search engines
Bug: Intermittent [TV] browser/components/translations/tests/browser/browser_translations_select_telemetry_keypresses_try_again_button.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerT
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2024-06-14 04:51:25+00:00
Resolved: 2024-06-19 01:46:13+00:00

**Filed by:** tszentpeteri [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=462316471&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/O4JtFRR9TryhFikte2I-fA/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/O4JtFRR9TryhFikte2I-fA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2024-06-14T04:14:40.184Z] 04:14:40     INFO - TEST-PASS | browser/components/translations/tests/browser/browser_translations_select_telemetry_keypresses_try_again_button.js | There should be 1 telemetry events of type translations.select_translations_panel.try_again_button - 
[task 2024-06-14T04:14:40.184Z] 04:14:40     INFO - Buffered messages logged at 04:14:39
[task 2024-06-14T04:14:40.185Z] 04:14:40     INFO - Leaving test bound test_select_translations_panel_invoke_translation_failure_try_again_button_with_space_bar
[task 2024-06-14T04:14:40.185Z] 04:14:40     INFO - Buffered messages finished
[task 2024-06-14T04:14:40.185Z] 04:14:40     INFO - TEST-UNEXPECTED-FAIL | browser/components/translations/tests/browser/browser_translations_select_telemetry_keypresses_try_again_button.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2024-06-14T04:14:40.186Z] 04:14:40     INFO - GECKO(4075) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2024-06-14T04:14:40.186Z] 04:14:40     INFO - GECKO(4075) | MEMORY STAT | vsize 8072MB | residentFast 317MB | heapAllocated 153MB
[task 2024-06-14T04:14:40.186Z] 04:14:40     INFO - TEST-OK | browser/components/translations/tests/browser/browser_translations_select_telemetry_keypresses_try_again_button.js | took 52681ms
[task 2024-06-14T04:14:40.186Z] 04:14:40     INFO - checking window state
[task 2024-06-14T04:14:40.187Z] 04:14:40     INFO - GECKO(4075) | Completed ShutdownLeaks collections in process 4075
[task 2024-06-14T04:14:40.187Z] 04:14:40     INFO - TEST-START | Shutdown
```
Bug: "About Nightly" dialog pads do nothing
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-06-14 05:12:13+00:00
Resolved: 2024-06-14 05:23:03+00:00

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

Steps to reproduce:

Click on the 3 lines button "menu".
Click on "Help".
Click on "About Nightly".


Actual results:

Nothing... No new window.


Expected results:

open a new little window in which Firefox give me the version of Nightly I use and if I have to download the update (quite twice a day)
Bug: All help options in dropdown menu are broken. Nothing is displayed on screen in nightly builds.
Status: NEW
Priority: --
Created: 2024-06-14 08:07:35+00:00
Resolved: 2024-06-14 08:55:20+00:00

This is a recent bug. I noticed all help options are not working anymore. Last time there were working was on wednesday June 12th.

Reproducing the bug ? Just grab a nightly starting on june 13th, go to help and try to open an option.
Bug: Tab preview flickers when the browser is moved to the bottom part of the screen
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-06-14 09:30:32+00:00
Resolved: 2024-08-20 20:52:43+00:00

**Found in**
* 128.0b2


**Affected versions**
* 129.0a1 (20240612215151)
* 128.0b2
	


**Tested platforms**
* Affected platforms: Windows 10x64, macOS 13
* Unaffected platforms: none


**Steps to reproduce**
1. Move the Firefox browser to bottom of the screen.
2. Open some random tabs and hover them.



**Expected result** 
* No flicker is visible.

**Actual result**
* Tab preview flickers on hover sometimes



**Regression range**
* This started happening with bug 1876522. After this fix the issue could be seen only if the tab was hovered for the first time. After  bug 1879089 the issue si more noticeable because it happens every time on hover.

**Additional notes**
* Attached a screen recording.
Bug: Tab preview is displayed for the previous hovered tab when moving the cursor to another tab at the right moment if the image preview is disabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-06-14 11:35:53+00:00
Resolved: 2024-06-26 12:53:41+00:00

**Found in**
* 128.0b2


**Affected versions**
* 129.0a1 (2025-06-13)
* 128.0b2
	


**Tested platforms**
* Affected platforms: Windows 10x64, Ubuntu
* Unaffected platforms: macOS 13

**Preconditions**
* browser.tabs.hoverPreview.enabled: true

**Steps to reproduce**
1. Disable Show an image preview when you hover on a tab from Preferences.
2. Open some random tabs.
3. Hover over a tab and move the mouse to the next tab.



**Expected result** 
* Tab preview is displayed for the correct tab.

**Actual result**
* Tab preview is displayed for the previous tab.



**Regression range**
* Before bug 1892394 the tab preview was displayed on the previous tab even if the mouse was on another tab which was caused by bug 1890397. After bug 1892394  is fixed the tab preview is displayed in the correct position on the currently hovered tab but the tab preview is for the previous tab.

**Additional notes**
* Attached is a screen recording.
* To reproduce the issue the tab hover needs to be changed right when the tab preview should appear.
* This only happens when `Show an image preview when you hover on a tab` is disabled.
Bug: VoiceOver does not announce accessible name of panels when they are opened and focused
Status: NEW
Priority: --
Created: 2024-06-14 13:42:46+00:00
Resolved: 2024-11-20 16:00:15+00:00

**Note**
* This is a follow-up from bug 1894094; The Panel has an accessible name, but VoiceOver does not read it when the panel is opened. 
* VoiceOver does, however, read the "Translation Beta" name when using the VoiceOver specific commands (VO+SHIFT+UP/DOWN) to navigate out of the panel and back in.

**Found in**
* Nightly v129.0a1

**Affected versions**
* Nightly v129.0a1
* Beta v128.0b3

**Tested platforms**
* Affected platforms: MacOS, Ubuntu (logged in a separate bug)
* Unaffected platforms: Windows

**Steps to reproduce**
1. Enable VoiceOver.
2. Launch the browser.
3. Ensure the feature is enabled: 
browser.translations.select.enable = TRUE
4. Load a webpage that is displayed in a different language than the browser.
5. Open the context menu on a selection of text, a link or an image.
6. Select the Translate option from the menu.
7. Observe the announcement of the panel by the VoiceOver.

**Expected result**
* The purpose of the dialog (its accessible name) is announced by a screen reader.

**Actual result**
* The accessible name is not announced by the screen reader. 
* It may be interrupted by the announcement of the translation process completion. (This is as assumption)

**Regression range**
* Not a regression.

**Additional notes**
* The accessible name is announced when the user navigates outwards using VoiceOver specific commands (VO+SHIFT+UP) or back inwards (VO+SHIFT+DOWN).
* The panel does have an accessible name implemented in bug 1894094.
Bug: The Translation Beta accessible name is not announced by ORCA when opening the Select Translations panel on Ubuntu
Status: NEW
Priority: --
Created: 2024-06-14 13:55:39+00:00
Resolved: 2024-09-06 05:42:59+00:00

**Note**
* This is a follow-up from bug 1894094; The Panel has an accessible name, but ORCA does not read it when the panel is opened.

**Found in**
* Nightly v129.0a1

**Affected versions**
* Nightly v129.0a1
* Beta v128.0b3

**Tested platforms**
* Affected platforms: Ubuntu, MacOS (logged in a bug 1902662)
* Unaffected platforms: Windows

**Steps to reproduce**
1. Enable ORCA.
2. Launch the browser.
3. Ensure the feature is enabled: 
browser.translations.select.enable = TRUE
4. Load a webpage that is displayed in a different language than the browser.
5. Open the context menu on a selection of text, a link or an image.
6. Select the Translate option from the menu.
7. Observe the announcement of the panel by the VoiceOver.

**Expected result**
* The purpose of the dialog (its accessible name) is announced by a screen reader.

**Actual result**
* The accessible name is not announced by the screen reader. 
* It is announced as a "dialog".

**Regression range**
* Not a regression.

**Additional notes**
* The panel does have an accessible name implemented in bug 1894094.
Bug: Screenshot mode is not exited when Enter key is pressed on the focused Cancel button
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-06-14 15:22:49+00:00
Resolved: 2024-06-21 02:52:20+00:00

**Found in**
* Firefox 128.0b2

**Affected versions**
* Firefox 127
* Firefox 128 Beta
* Nightly 129.0a1

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

**Steps to reproduce**
1. Navigate to any website and enable Screenshots by pressing Ctrl/Cmd+Shift+S keys.
2. Place the mouse somewhere on the Screenshot overlay.
3. Use the Tab key to navigate to the Cancel button.
4. Press the Enter key.

**Expected result**
* Screenshot mode should be exited when the Enter Key is pressed while the Cancel button is in focus.

**Actual result**
* Instead of exiting Screenshots mode, a new area is selected. 
* This behaviour is not encountered when pressing Space instead of Enter.

**Regression range**
* The issue is present in all curent versions, not sure if it's a regression. I'll investigate more as soon as possible.
Bug: TranslationsParent.getTopPreferredSupportedToLang returns false positives
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-06-14 17:29:00+00:00
Resolved: 2024-06-21 14:44:22+00:00

### Description

When I landed the [TranslationsParent.getTopPreferredSupportedToLang()](https://searchfox.org/mozilla-central/rev/d31f750ad9e5b6c8f7b62d387dbea3f804044350/toolkit/components/translations/actors/TranslationsParent.sys.mjs#2412-2420) function, I did not sufficiently test all edge cases. I recently discovered that this function is capable of returning a false positive.

It always returns the first language in the preferred languages list, regardless of its supported status. 

This works out for languages that we support, but for a language such as Finnish, which, at the time of writing, is only supported as a source language and not a target language, this will return a false positive. 

---

### Steps to reproduce

* Download [Firefox Nightly](https://www.mozilla.org/en-US/firefox/all/#product-desktop-nightly) in a language that is not supported as a translations target language, e.g. Finnish at the time of writing. 
* Navigate to a web page, e.g. https://es.wikipedia.org.
* Select some text.
* Open the right-click context menu.

**Expected Behavior**
The context menu offers to translate the text to **English** since the app locale language is not supported as a translations target.

**Actual Behavior**
The context menu offers to translate the text to the **app locale language**, even though it is not supported. 

---

### Steps to implement

* Fix the [TranslationsParent.getTopPreferredSupportedToLang()](https://searchfox.org/mozilla-central/rev/d31f750ad9e5b6c8f7b62d387dbea3f804044350/toolkit/components/translations/actors/TranslationsParent.sys.mjs#2412-2420) to properly await functions that it calls. 

---

### Tests to implement

* Add tests for this function in various supported/unsupported app locales.
Bug: The default screenshot tool now cuts off the file name after the date almost every time. Thus, the capture time no longer appears and poses a problem when saving file if several captures are made in the same day.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-06-14 17:41:39+00:00
Resolved: 2024-08-15 12:26:50+00:00

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

Steps to reproduce:

Use the default screenshot tool.


Actual results:

As of a few days ago, the default screenshot tool now cuts off the file name after the date almost every time. Thus, the capture time no longer appears and poses a problem when saving the file if two, three or more captures are made in the same day, because these screenshot files have the same name.


Expected results:

Could we revert to the previous version, or cut after the hour-minute-second of the default file name? Thanks in advance for this correction.
Bug: deduplicating tabs should ignore fragment
Status: NEW
Priority: --
Created: 2024-06-14 19:13:07+00:00
Resolved: 2024-07-09 13:54:52+00:00

When deciding whether two tabs could be deduplicated Firefox should ignore (or at least optionally) path fragments:

https://github.com/Flask-Middleware/flask-security/issues/531 and
https://github.com/Flask-Middleware/flask-security/issues/531#issuecomment-934553305

should be recognized as identical tabs.
Bug: Failed to navigate to link from `History`
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-06-14 20:37:18+00:00
Resolved: 2024-06-17 15:22:46+00:00

I'm using mozilla-central based on `changeset: 826469:b7e7920a4ec6` which is from June 12th. Now all the links from `History` didn't take any effect. When I clicked the link from `History` I wanted to navigate to, nothing would happen.
Bug: Opening a link in a new tab creates it then moves it after a short time
Status: UNCONFIRMED
Priority: --
Created: 2024-06-14 21:35:29+00:00
Resolved: 2024-07-11 23:42:49+00:00

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

Steps to reproduce:

Create a bunch of tabs from different sites.
Let's say for example, I have Reddit and Bugzilla opened.
I open a bunch of reddit topics in a new tab, the tab order is such :
Reddit Front Page | Reddit Topic 1 | Reddit Topic 2 | Bugzilla

Then I go back to the reddit front page and open a third topic in a new tab


Actual results:

The new tab was first located next to the current tab, then it moved, and between those two events resides just enough time for a user to move his mouse and missclick because of this.
The first event (tab is created) :
RFP | RT3 | RT1 | RT2 | BZLA
The second event (tab moves to the "right position" after a short time):
RFP | RT1 | RT2 | RT3 | BZLA



Expected results:

The new tab is directly put in the right position,
To keep the example, what should have happened instantly is this (tab is created in the right position with no suddent displacement):
RFP | RT1 | RT2 | RT3 | BZLA

This happened recently, though I could not pinpoint at which moment exactly in the updates, sorry.
Bug: Intermittent uriloader/exthandler/tests/mochitest/browser_protocol_ask_dialog.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-06-14 23:41:38+00:00
Resolved: 2025-02-17 12:05:26+00:00

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

---
```
TEST-PASS | uriloader/exthandler/tests/mochitest/browser_protocol_ask_dialog.js | The dialog should have been closed. - 
[task 2024-06-14T23:29:50.027Z] 23:29:50     INFO - Leaving test bound test_closed_by_tab_closure
[task 2024-06-14T23:29:50.028Z] 23:29:50     INFO - Entering test bound test_closed_by_tab_navigation
[task 2024-06-14T23:29:50.029Z] 23:29:50     INFO - Buffered messages logged at 23:28:20
[task 2024-06-14T23:29:50.029Z] 23:29:50     INFO - Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "https://example.com/browser/uriloader/exthandler/tests/mochitest/file_nested_protocol_request.html" line: 0}]
[task 2024-06-14T23:29:50.030Z] 23:29:50     INFO - Buffered messages logged at 23:29:04
[task 2024-06-14T23:29:50.031Z] 23:29:50     INFO - Longer timeout required, waiting longer...  Remaining timeouts: 1
[task 2024-06-14T23:29:50.031Z] 23:29:50     INFO - Buffered messages finished
[task 2024-06-14T23:29:50.031Z] 23:29:50     INFO - TEST-UNEXPECTED-FAIL | uriloader/exthandler/tests/mochitest/browser_protocol_ask_dialog.js | Test timed out - 
[task 2024-06-14T23:29:50.031Z] 23:29:50     INFO - GECKO(9886) | Completed ShutdownLeaks collections in process 9886
[task 2024-06-14T23:29:50.031Z] 23:29:50     INFO - TEST-START | Shutdown
```
Bug: Geolocation request notification popup cannot be dismissed
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-06-15 12:41:49+00:00
Resolved: 2024-07-30 13:33:34+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

Steps to reproduce:

1) Go to https://www.ozon.ru (or any site with geolocation request)
2) Do not answer on question about geolocation


Actual results:

I can't close notification


Expected results:

I can close notification without answering permission request.
Bug: Zooming in a PDF zooms the UI too
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-06-16 00:01:19+00:00
Resolved: 2024-10-27 15:30:17+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:

Opening a PDF in Firefox 127 on MacBook and zooming with the trackpad will zoom the UI, too. This is of course nonsense. Only the content should be zoomable, not the UI.