av9ash/GitBugs huggingface dataset:
Bug: Pinning from private_browsing.exe on newer versions of Windows fails
Status: NEW
Priority: P4
Created: 2024-04-29 19:15:07+00:00
Resolved: 2024-04-29 19:15:07+00:00

On newer versions of Windows (first seen in version 10.0.26052.1100 - Windows 11 24H2, as yet only available from the Windows Insider Program), private_browsing is unable to pin to the taskbar.

Found in

FX 123

Affected versions

All versions with pinning to the taskbar

Tested platforms

Affected platforms: Windows 10x64
Unaffected platforms: macOS 13, Ubuntu 22.1, Windows 11

Preconditions

Unpin Firefox Private from the taskbar and make sure that another browser is the system default browser. Close all instances of Firefox.

Steps to reproduce

Launch private_browsing.exe.
Go to about:welcome if it doesn't go there automatically.
Click yes on the prompt to make Firefox the default browser and pin it to the taskbar.

Expected result

Firefox Private is pinned to the taskbar

Actual result

Firefox private is NOT pinned to the taskbar and the user gets no feedback explaining that it isn't pinned.

Regression range

Not a regression

Additional notes

Happens since pinning was introduced into the installer, and only on newer versions of Windows.
Bug: Pinning tabs in Firefox does not work on Windows 24H2 and newer
Status: NEW
Priority: P4
Created: 2024-04-29 19:18:33+00:00
Resolved: 2024-04-30 01:09:13+00:00

The tab pinning extension has functionality to pin a tab to the Windows taskbar. In Windows 24H2 (and newer versions, presumably), this does not work any longer.

Note that Windows 24H2 is only available as of April 29, 2024 via the Windows Insider Program. It has not been officially released yet.
Bug: Repeated language names in to/from Translation Options
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-04-29 19:27:21+00:00
Resolved: 2024-05-14 15:44:21+00:00

STR:
* Navigate to a translatable webpage, not in the UI language.
   * e.g., on an English app, navigate to https://www.mozilla.org/fr/
* Press translate from the toolbar
* Change to/from languages
* Observe the list of language names is repeated a few times.
* If the names are not repeated, open close the translations dialog or the dropdowns a few times or wait. 
    * Sometimes the first time the dropdown is opened, there are no repeated names.

Observed in Firefox Desktop Release for MacOS v125.0.3. Not observed in Nightly 127.0a1 (2024-04-26) or 127.0a1 (2024-04-29).
Bug: A screen reader does not announce when a translation is added on the Select Translations panel
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-04-29 20:18:24+00:00
Resolved: 2024-06-13 17:25:33+00:00

### STR:
1. Ensure `browser.translations.select.enable` is set to `true` in the about:config 
1. Ensure an NVDA screen reader is running
1. Navigate to a page in a language different from the OS, i.e. for English machine: `data:text/html,<p lang="es_ES">Como estas?</p>` or https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BB%D0%BE%D0%B6%D0%B5%D0%BA
1. Select a text (using mouse or by following the [NVDA 2024.1 guide for Native Selection Mode](https://www.nvaccess.org/files/nvda/documentation/userGuide.html?#NativeSelectionMode)) and open a context menu/right click
1. Navigate to and activate `Translate Selection to English`
1. Confirm the dialog is opened and observe the screen reader announcements:
    1. When the dialog is opened and the focus is placed on the `<textarea[readonly]>` while the translation is in progress and the placeholder `Translating...` is announced
    1. Once the translation is completed, observe the change in the announcement

### Expected:
1. Once the translation is completed and the placeholder is replaced with the translated text, this translated text is announced by a screen reader.

### Actual:
1. Once the translation is completed and the placeholder is replaced with the translated text, nothing is being announced by a screen reader. User will have to navigate away from the focused area and re-focus it to hear the translated text.

### Note:
NVDA on Windows 11 did not announce the textarea change (the dialog is `alertdialog`) while VoiceOver on macOS Sonoma 14.4.1 did announce the change, as expected.
Bug: Select Translations panel is missing accessible name
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-04-29 20:38:58+00:00
Resolved: 2024-06-19 00:27:18+00:00

### STR:
1. Ensure `browser.translations.select.enable` is set to `true` in the about:config 
1. Ensure a screen reader is running
1. Navigate to a page in a language different from the OS, i.e. for English machine: `data:text/html,<p lang="es_ES">Como estas?</p>` or https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BB%D0%BE%D0%B6%D0%B5%D0%BA
1. Select a text (using mouse or by following the [NVDA 2024.1 guide for Native Selection Mode](https://www.nvaccess.org/files/nvda/documentation/userGuide.html?#NativeSelectionMode)) and open a context menu/right click
1. Navigate to and activate `Translate Selection to English`
1. Confirm the dialog is opened and observe the screen reader announcements:

### Expected:
1. The purpose of the dialog (its accessible name) is announced by a screen reader.

### Actual:
1. Only the dialog role itself is announced by screen readers, but the label for the dialog is missing. Users of assistive technology may be confused what is the purpose of the dialog and why did it open.

### Remediation:
1. Add to the `role=alertdialog` container an [aria-labelledby](https://w3c.github.io/aria/#aria-labelledby) reference to the `<h1>` ID attribute that would provide an accessible name - `Translations BETA` or `Translations`
1. (bug 1894098) To the dialog container, also add [aria-describedby](https://w3c.github.io/aria/#aria-describedby) reference to the ID attribute of the dialog itself - this would allow a screen reader to also read the content of the dialog to a user while the focus is placed not at the top of the dialog, without the need to reverse navigate it.
Bug: Content of the Select Translations panel is not announced to a screen reader user when the panel is opened
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-04-29 20:53:48+00:00
Resolved: 2024-06-21 19:10:26+00:00

### STR:
1. Ensure `browser.translations.select.enable` is set to `true` in the about:config 
1. Ensure a screen reader is running
1. Navigate to a page in a language different from the OS, i.e. for English machine: `data:text/html,<p lang="es_ES">Como estas?</p>` or https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BB%D0%BE%D0%B6%D0%B5%D0%BA
1. Select a text (using mouse or by following the [NVDA 2024.1 guide for Native Selection Mode](https://www.nvaccess.org/files/nvda/documentation/userGuide.html?#NativeSelectionMode)) and open a context menu/right click
1. Navigate to and activate `Translate Selection to English`
1. Confirm the dialog is opened and observe the screen reader announcements

### Expected:
1. When a dialog is opened, [it is expected that the focus would be placed to allow the user to discover the content of the dialog without the need to navigate backwards](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/#keyboardinteraction), which is usually for the content to be placed at the top of the content or on the container itself _or_ to the main action but while making sure [the content of the alertdialog would be announced by a screen reader](https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/).
    1. In this case, since the size of the dialog is short, and the primary action/target of the dialog is the translation, we could retain the focus on the `<textarea>` but it's important to use `aria-describedby` that is referring to the container of the dialog, to its content, so a screen reader user would become aware that there is, in fact, some content and controls that are placed above the current focus position.

### Actual:
1. Only the dialog role itself is announced by screen readers, no information is provided about the settings or to/from language controls. Focus is placed on the translated output itself, which may cause users of assistive technology to think that there are no other content above, no way to toggle the to/from languages and/or change the translation settings.

### Remediation:
1. To the `role=alertdialog` container, add `aria-describedby` reference to the ID attribute of the dialog itself - this would allow a screen reader to also read the content of the dialog to a user while the focus is placed not at the top of the dialog, without the need to reverse navigate it. Refer to [the WAI ARIA alertdialog pattern](https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/)
Bug: BETA badge on the Select Translations panel is hidden from assistive technology
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-04-29 21:02:12+00:00
Resolved: 2024-05-31 13:41:40+00:00

### STR:
1. Ensure `browser.translations.select.enable` is set to `true` in the about:config 
1. Ensure a screen reader is running
1. Navigate to a page in a language different from the OS, i.e. for English machine: `data:text/html,<p lang="es_ES">Como estas?</p>` or https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BB%D0%BE%D0%B6%D0%B5%D0%BA
1. Select a text (using mouse, likely, because screen readers are not yet supporting static text selection) and open a context menu/right click
1. Navigate to and activate `Translate Selection to English`
1. With a screen reader, navigate to the heading of the dialog and observe the screen reader announcements:

### Expected:
1. The `BETA` badge is announced by a screen reader. Ideally, as a part of the heading announcement, but as a separate element would also be appropriate.

### Actual:
1. The `BETA` badge is hidden from assistive technology. Users of screen readers would not know that the feature is still, in fact, in Beta.

### Remediation:
1. Ensure the image is [marked up as informative](https://www.w3.org/WAI/tutorials/images/informative/). Since this `<image>` is wrapped in an `hbox`, try adding `role=image` and `aria-label="Beta"` to the `<hbox>`.
1. Another way is to include `Beta` in the `<h1>` announcement
Bug: Opening bookmarks folder has delay or failure to draw bookmarks
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-04-29 21:14:53+00:00
Resolved: 2024-05-02 13:03:12+00:00

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

Steps to reproduce:

Updated to today's nightly build.

Open bookmark folder present on the bookmarks toolbar. (This does not appear to happen in the general bookmarks menu, at least with minimal testing.)



Actual results:

The bookmarks in the folder are not fully drawn when the folder opens. There might be a fraction of a second delay before the rest of the bookmarks are displayed (more likely), or the remaining bookmarks may not be displayed at all (less likely).

Generally, once the bookmarks have been drawn once, they will show up properly on subsequent openings of that particular folder. It loses the "fixed" state after a reboot, and possibly after a long period of non-use.


Expected results:

All bookmarks in a folder should display promptly when the folder is opened.
Bug: Use after free in nsWindowsShellService::ClassifyShortcut
Status: RESOLVED
Priority: P3
Resolution: INVALID
Created: 2024-04-29 21:18:17+00:00
Resolved: 2024-04-30 02:38:15+00:00

We're currently using `CoTaskMemFree()` on `PWSTR rawPath` and then accessing `knownPath nsDependentString(rawPath)` afterwards. This doesn't look like it's currently posing issues as we can conceivably access the dangling `rawPath` pointer before the memory is overwritten with something else but this should be fixed.
Bug: Intermittent browser/components/customizableui/test/browser_overflow_use_subviews.js | single tracking bug
Status: REOPENED
Priority: P5
Created: 2024-04-30 01:34:14+00:00
Resolved: 2025-02-17 06:45:34+00:00

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

---
```
[task 2024-04-30T01:09:31.355Z] 01:09:31     INFO - TEST-PASS | browser/components/customizableui/test/browser_overflow_use_subviews.js | Should be inside the panel - 
[task 2024-04-30T01:09:31.355Z] 01:09:31     INFO - Buffered messages logged at 01:09:11
[task 2024-04-30T01:09:31.356Z] 01:09:31     INFO - Leaving test bound check_library_subview_in_overflow
[task 2024-04-30T01:09:31.357Z] 01:09:31     INFO - Entering test bound check_downloads_panel_in_overflow
[task 2024-04-30T01:09:31.357Z] 01:09:31     INFO - Waiting for overflow button to show
[task 2024-04-30T01:09:31.358Z] 01:09:31     INFO - Checking if element has non-0 size
[task 2024-04-30T01:09:31.358Z] 01:09:31     INFO - Buffered messages finished
[task 2024-04-30T01:09:31.359Z] 01:09:31     INFO - TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_overflow_use_subviews.js | Uncaught exception in test bound check_downloads_panel_in_overflow - Panel did not show within 20 seconds.
[task 2024-04-30T01:09:31.360Z] 01:09:31     INFO - Leaving test bound check_downloads_panel_in_overflow
[task 2024-04-30T01:09:31.460Z] 01:09:31     INFO - GECKO(10144) | MEMORY STAT | vsize 2112693MB | vsizeMaxContiguous 65203447MB | residentFast 432MB | heapAllocated 131MB
[task 2024-04-30T01:09:31.461Z] 01:09:31     INFO - TEST-OK | browser/components/customizableui/test/browser_overflow_use_subviews.js | took 21103ms
```
Bug: When opening local PDFs, only the text after the last hashtag (#, if it exists) is shown as the tab title (e.g. output#1.pdf shows up as 1.pdf).
Status: NEW
Priority: P3
Created: 2024-04-30 06:22:05+00:00
Resolved: 2024-05-22 08:06:56+00:00

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

Steps to reproduce:

Open any PDF with a hashtag: e.g. one#two#three.pdf


Actual results:

A new tab with title "three.pdf" was shown.


Expected results:

The tab title should have been "one#two#three.pdf"
Bug: Tab switches to/from tabs with tab-specific infobars cause viewport height to change, resulting in layout jank
Status: NEW
Priority: P3
Created: 2024-04-30 10:03:38+00:00
Resolved: 2024-06-07 12:07:45+00:00

Steps to reproduce:
1) Navigate to attachment 9399318
2) Create a notification 
3) Switch to a YouTube tab

Actual results:
Jank/layout shifting 

Expected results:
No jank/layout shifting
Bug: Intermittent browser/components/downloads/test/browser/browser_overflow_anchor.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-04-30 12:03:57+00:00
Resolved: 2025-01-27 12:04:01+00:00

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

---
```
[task 2024-04-30T10:12:09.914Z] 10:12:09     INFO - TEST-PASS | browser/components/downloads/test/browser/browser_overflow_anchor.js | Button should know it's in the toolbar - 
[task 2024-04-30T10:12:09.914Z] 10:12:09     INFO - waiting for panel to open
[task 2024-04-30T10:12:09.915Z] 10:12:09     INFO - Console message: [JavaScript Warning: "initMouseEvent() is deprecated. Use the MouseEvent() constructor instead." {file: "chrome://mochikit/content/tests/SimpleTest/EventUtils.js" line: 296}]
[task 2024-04-30T10:12:09.915Z] 10:12:09     INFO - Buffered messages finished
[task 2024-04-30T10:12:09.916Z] 10:12:09     INFO - TEST-UNEXPECTED-FAIL | browser/components/downloads/test/browser/browser_overflow_anchor.js | Test timed out - 
[task 2024-04-30T10:12:09.917Z] 10:12:09     INFO - GECKO(8432) | Completed ShutdownLeaks collections in process 5348
[task 2024-04-30T10:12:09.917Z] 10:12:09     INFO - TEST-START | Shutdown
```
Bug: High Contrast does not properly apply on WIndows
Status: NEW
Priority: P4
Created: 2024-04-30 12:28:14+00:00
Resolved: 2024-06-19 15:10:56+00:00

**Note**
* When the user sets a High Contrast Theme in Windows and then triggers the Select Translations panel, he will notice that the colors don't properly apply to the panel.

**Found in**
* Nightly v127.0a1

**Affected versions**
* Nightly v127.0a1

**Tested platforms**
* Affected platforms: Windows 10/11
* Unaffected platforms: MacOS, Ubuntu 

**Steps to reproduce**
1. Enable High Contrast Theme on Windows
2. Open a webpage that is displayed in a different language than the browser's.
3. Open the context menu on a selection of text or on a link.
4. Select the Translate option.
5. Observe the panel's colors.

**Expected result**
* The selected High Contrast Theme colors properly apply to the panel.

**Actual result**
* The selected High Contrast Theme colors do not apply to the panel.

**Regression range**
* This is not a regression.

**Additional notes**
* This issue is more visible in the case of the High Contrast 1, High Contrast 2 Themes, but it also occurs for the High Contrast White and High Contrast Black Themes as there should be more contrast than it has by default.
Bug: Navigating inside the translated text box using UP/DOWN ARROWs is not working correctly
Status: VERIFIED
Priority: P4
Resolution: FIXED
Created: 2024-04-30 13:12:06+00:00
Resolved: 2024-06-19 00:27:16+00:00

**Note**
* When the user selects a larger paragraph of text and triggers the Select Translations panel, he will need to navigate inside the text box to read all the translated text. When tapping the DOWN ARROW once, the panel scrolls to the very end of the text. Then if he taps the UP ARROW, the focus will move from the last row, one row at a time, without any visual effect of the focus, until the focus reaches the top of the text area (~12 presses of the UP ARROW), only then, the text is scrolled up, one row at a time. Scrolling back down will happen just the same, ~12 ghost taps until the text is being scrolled. Both the scrolling down and scrolling up using the keyboard is ineffective.

**Found in**
* Nightly v127.0a1

**Affected versions**
* Nightly v127.0a1

**Tested platforms**
* Affected platforms: Windows, MacOS, Ubuntu
* Unaffected platforms: -

**Steps to reproduce**
1. Select a very large paragraph of text.
2. Open the context menu and select the Translate option.
3. Tap the DOWN ARROW button.
**Expected result:** The text is being scrolled 1 or a few rows at a time.
**Actual result:** The text is being scrolled to the end.
4. Tap the UP ARROW button.
**Expected result:** The text is being scrolled 1 or a few rows at a time.
**Actual result:** The text does not scroll up for the first 12 taps, then scrolls one row at a time.

**Regression range**
* Not a regression.
Bug: Folder upload is broken with DLP on
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-04-30 15:13:52+00:00
Resolved: 2024-05-06 09:51:54+00:00

We're hitting a failure in nsFilePicker::CheckContentAnalysisService() in the `modeGetFolder` case which causes nothing to happen (no DLP request, no folder gets uploaded)
Bug: Errors on the Select Translations panel are not announced when they appear
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-04-30 15:42:44+00:00
Resolved: 2024-05-31 11:16:44+00:00

### STR:
1. Ensure `browser.translations.select.enable` is set to `true` in the about:config 
    * to trigger errors intermittently, activate the Chaos mode via: `browser.translations.chaos.errors=true` and then setting `browser.translations.chaos.timeoutMS` to `1000` (1 sec) or similar
1. Ensure a screen reader is running
1. Navigate to a page in a language different from the OS, i.e. for English machine: `data:text/html,<p lang="es_ES">Como estas?</p>` or https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BB%D0%BE%D0%B6%D0%B5%D0%BA
1. Select a text (using mouse or by following the [NVDA 2024.1 guide for Native Selection Mode](https://www.nvaccess.org/files/nvda/documentation/userGuide.html?#NativeSelectionMode)) and open a context menu/right click
1. Navigate to and activate `Translate Selection to English`
1. When a Translation panel opens _with an error_, observe the screen reader announcement
    * If the error state is not shown after 1 sec (or other timeout that was set in the custom pref), re-open the panel by pressing `Esc` and repeating steps 4-6.

### Expected:
1. The text of error is announced by a screen reader. 

### Actual:
1. The text of error is added to the panel but it is not announced by the assistive technology. The focus is set to the `Try again` button by default but it is not clear why it should be tried again. Users of screen readers would not be aware of the error, unless they'll navigate backwards in [browse mode of a screen reader](https://www.accessibility-developer-guide.com/knowledge/screen-readers/desktop/browse-focus-modes/).

### Remediation:
1. Either add `tabindex="-1"` to the error container and place the focus on it by default, _or_
1. Add [aria-describedby](https://w3c.github.io/aria/#aria-describedby) attribute to the `Try again` button and reference the `id` of the error container, i.e. `aria-describedby="select-translations-panel-translation-failure-message-bar"`. More than one `id` could be referenced when separated with a space
Bug: Only load attachments from dumps when on production
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-04-30 15:51:56+00:00
Resolved: 2024-05-08 21:23:19+00:00

When we're not on production, we still try to load attachments from the local dumps. I think this generally only matters if there's id conflicts between stage & production, however I did manage to set search-config-icons up with id conflicts, which is why I'm seeing it. It would be likely to potentially cause confusion if we update stage with new versions of icons.

I missed this when I implemented bug 1891788. 

STR

1. On latest nightly, load a fresh profile & check search settings -> the search engines all should have icons.
2. Using remote-settings-devtools, switch to "Stage" and clear all local data.
3. Restart nightly.

Expected Results

The application provided search engines should not have icons until the app has been idle for 20 seconds.

Actual Results

The search engines do have icons, which have been loaded from the dumps.
Bug: Backup manifest schema violation warning emitted when not signed in
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-04-30 17:27:57+00:00
Resolved: 2024-05-02 04:10:51+00:00

STR:

1. Don't be signed into a Mozilla account
2. Visit chrome://browser/content/backup/debug.html
3. Click "Create backup"
4. Open the Browser Console

ER:

Perhaps some logging, but no errors.

AR:

This error is displayed:

```
BackupService: Backup manifest does not conform to schema: 
Object { version: 1, meta: {…}, resources: {…} }
 
Object { "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "file:///BackupManifest.schema.json", title: "BackupManifest", description: "A schema for the backup-manifest.json file for profile backups created by the BackupService", type: "object", properties: {…}, required: (3) […] }
 
Object { valid: false, parsedValue: undefined, error: JsonSchemaValidatorError }
BackupService.sys.mjs:283:25
```

This is because of some properties set to undefined in the `meta` object when not signed into an account.