av9ash/GitBugs huggingface dataset:
Bug: Intermittent toolkit/components/pdfjs/test/browser_pdfjs_alttext_load_engine.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-07-24 01:53:57+00:00
Resolved: 2024-09-02 12:02:47+00:00

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

---
```
[task 2024-07-24T01:34:05.203Z] 01:34:05     INFO - TEST-PASS | toolkit/components/pdfjs/test/browser_pdfjs_alttext_load_engine.js | pdf handler defaults to internal - 
[task 2024-07-24T01:34:05.203Z] 01:34:05     INFO - Pref action: 3
[task 2024-07-24T01:34:05.203Z] 01:34:05     INFO - Buffered messages logged at 01:32:35
[task 2024-07-24T01:34:05.203Z] 01:34:05     INFO - Console message: [JavaScript Warning: "Partitioned cookie or storage access was provided to “https://example.com/browser/toolkit/components/pdfjs/test/file_pdfjs_test.pdf” because it is loaded in the third-party context and dynamic state partitioning is enabled."]
[task 2024-07-24T01:34:05.204Z] 01:34:05     INFO - Buffered messages logged at 01:32:37
[task 2024-07-24T01:34:05.205Z] 01:34:05     INFO - TEST-PASS | toolkit/components/pdfjs/test/browser_pdfjs_alttext_load_engine.js | AltText is enabled - 
[task 2024-07-24T01:34:05.206Z] 01:34:05     INFO - Resolving 1 mocked downloads for "test-translation-wasm-0"
[task 2024-07-24T01:34:05.207Z] 01:34:05     INFO - Buffered messages finished
[task 2024-07-24T01:34:05.207Z] 01:34:05     INFO - TEST-UNEXPECTED-FAIL | toolkit/components/pdfjs/test/browser_pdfjs_alttext_load_engine.js | Test timed out - 
[task 2024-07-24T01:34:05.208Z] 01:34:05     INFO - GECKO(1108) | Completed ShutdownLeaks collections in process 1108
[task 2024-07-24T01:34:05.208Z] 01:34:05     INFO - TEST-START | Shutdown
```
Bug: Sidebar settings and status are not saved when exiting
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-24 06:56:43+00:00
Resolved: 2024-10-11 11:01:51+00:00

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

Steps to reproduce:

Starting Firefox (Windows)


Actual results:

When Firefox starts, the status of the sidebar (bookmarks) before version 128.0 is displayed, such as size, on/off, etc. The current changes are not saved and called up.
The reason: No new data is written to the xulstore file
After deleting the xulstore, a new file is created, but this is no longer changed.
Bug: Tab hover is displayed for a random tab during the process of dragging a tab
Status: NEW
Priority: P5
Created: 2024-07-24 08:00:31+00:00
Resolved: 2025-02-01 06:38:39+00:00

**Found in**
* Nightly 130.0a1

**Affected versions**
* Nightly 130.0a1

**Tested platforms**
* Affected platforms: MacOS 13.6
* Unaffected platforms: Windows 11, Ubuntu 22.04

**Preconditions**
* Have the `browser.tabs.cardPreview.enabled` pref set to `true`

**Steps to reproduce**
1. Visit a few websites in different tabs.
2. Click on a tab and move it in the tab strip (change its position).

**Expected result**
* Only the preview of the dragged tab is displayed after completing the action and leaving the cursor on the tab.

**Actual result**
* Sometimes while in the process of dragging a tab a hover is displayed near the previous location of the tab that is currently dragged.

**Regression range**
* This happened after the fix from bug 1907967. Previous to that, I ran into the behavior from bug 1881782.
Bug: Dismiss events should record a `position` property when Merino is enabled
Status: NEW
Priority: --
Created: 2024-07-24 11:37:15+00:00
Resolved: 2024-08-07 12:14:55+00:00

**[Affected versions]:**
- Firefox Nightly 130.0a1 - Build ID: 20240722214643
- Firefox Beta 129.0b7 - Build ID: 20240722091823

**[Affected Platforms]:**
- Windows 10
- macOS 14
- Ubuntu 22

**[Prerequisites]:**
- Have a Firefox build installed and use a new profile.
- Have the `browser.newtabpage.activity-stream.discoverystream.merino-provider.enabled` pref set to `true`.

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites and open a new tab.
2. Navigate to about:glean.
3. Set a custom debug tag and select `newtab` from the dropdown.
4. Open a new tab and dismiss one of the cards from the "Thought-provoking stories" section.
5. Switch to the about:glean tab and click "Apply settings and submit".
6. Navigate to the https://debug-ping-preview.firebaseapp.com/pings/custom-debug-tag page and click the newtab ping that contains dismiss data.

**[Expected result]:**
- Ping data contains a `position`.
 
**[Actual result]:**
- Ping data contains all the required fields except `position`.

**[Notes]:**
- The position is successfully recorded for `impression` and `click` events.
- The issue is not a recent regression based on the following regression window, I've managed to reproduce the behavior ever since we landed the capability to switch to Merino in bug 1904594.

15:51.90 INFO: Last good revision: 06865dfc4ec5ed89afba354fe1ec275242a11e4a
15:51.90 INFO: First bad revision: 9901802eb71a05825b2e461cfacbd12e0838c8ce
15:51.90 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=06865dfc4ec5ed89afba354fe1ec275242a11e4a&tochange=9901802eb71a05825b2e461cfacbd12e0838c8ce
Bug: Page content disappears when auto-translate is enabled.
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-07-24 11:53:24+00:00
Resolved: 2025-01-18 17:36:48+00:00

**Environment:**
Operating system: Windows 10
Firefox version: Firefox 128.0 (release)/ Firefox Nightly 130

**Preconditions:**
- ETP set to STRICT
- Clean profile

**Steps to reproduce:**
1. Navigate to: https://schnapsen.online/spielen
2. Click on Register

**Expected Behavior:**
Registration page displayed

**Actual Behavior:**
The registration page is not displayed properly

**Notes:**
- Not reproducible with ETP STANDARD/turned OFF (both Normal and Private Browsing)
- Reproducible on the latest Nightly

---

Created from webcompat-user-report:83020685-935c-45bc-b2d6-529ecc340dd0
Bug: Enhanced tracking protection (ETP) radio options have no focus styling
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-07-24 15:31:11+00:00
Resolved: 2024-08-16 08:31:54+00:00

Noticed in 128.

Steps to reproduce:

1. Go to "Privacy & Security", "Enhanced Tracking Protection" settings.
2. Tab with the keyboard to focus the selected radio option.

Result: No styling to indicate where the focus has gone.

Expect: Some styling, at least around the radio circle.

I think this was introduced by bug 1867769, which removed the old focus styling rule. And may be a limitation of [this styling rule, which only works if the `<radio>` is a direct child of `<radiogroup>`](https://searchfox.org/mozilla-esr128/rev/4754fe8f631cb47b1994721f738029275f8aad0a/toolkit/themes/shared/radio.css#36-38). Not sure if there was a specific reason to have the strict child requirement.
Bug: Switching to a tab whose urlbar was cleared restores the URL but doesn't select it
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-07-24 16:04:20+00:00
Resolved: 2024-08-05 11:42:12+00:00

Steps:
1. Load www.mozilla.org in a tab
2. open a second tab
3. switch to the first tab, focus the urlbar and delete the url, so the field remains empty
4. switch to the second tab
5. switch back to the first tab

Expected Result:
The mozilla.org url should be restored in the first tab and it should be fully selected

Actual Result:
The mozilla.org is restored in the first tab, but the cursor is at index 0
Bug: Startup is set to "Open previous windows and tabs" but only the Firefox homepage opens.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-07-24 16:22:20+00:00
Resolved: 2024-07-30 17:50:28+00:00

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

Steps to reproduce:

In Firefox 128.0.2 (64-bit), I chose Settings > General > Startup > Open previous windows and tabs.


Actual results:

On startup, Firefox opened the homepage -- as set in Settings > Home > New windows and tabs > Homepage and New Windows.


Expected results:

The tabs that were open in the previous browsing session should have been loaded.
Bug: When newtab weather widget is in "data not available" state, the entire widget changes color when I click the 3-dot menu
Status: NEW
Priority: P3
Created: 2024-07-24 16:40:06+00:00
Resolved: 2024-11-19 03:58:37+00:00

STR:
1. Get into a state where your new tab shows "Weather data is not available right now."
~(I'm not sure how to manually get into that state, but I'm occasionally in that state for a little while after opening Firefox Nightly in the morning.)~
EDIT: I found a way to reliably trigger this state -- just fully disconnect your machine from the network, and then start Firefox with a fresh user-profile (using e.g. `about:profiles` to create a new profile, or `firefox -profile ~/dummy-profile/` (where `~/dummy-profile/` is an empty folder that you've just created)

2. Click the 3-dot menu on the right edge of the weather widget.

ACTUAL RESULTS:
The whole weather widget illuminates as if it was clicked.

EXPECTED RESULTS:
Only the 3-dot menu should illuminate.


ADDITIONAL NOTES:
* Once the weather data successfully loads, then I get expected-results.  This bug seems to specifically affect the widget when it's in its fallback data-not-available state.
* So far I've only tested this with the dark new-tab UI (from setting a dark color-scheme preference in about:preferences). I assume it affects the light-themed UI as well, but I haven't tested that yet.
* Screen-recordings attached, recorded with Firefox Nightly 130.0a1 (2024-07-23) (64-bit) on Ubuntu 22.04
Bug: The active tab indication doesn't change color on sidebar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-24 17:03:05+00:00
Resolved: 2024-07-26 13:38:25+00:00

Currently the only indicator for the active tab in sidebar tabs is the gray box shadow, but we also need to change the color too (bright white on light theme and light gray on dark theme). Currently it stays with the same color on light theme and slightly-light gray on dark theme, which makes it harder to notice, especially on dark theme)

Bug 1886847 doesn't seem to cover this (my local build with D216748 shows the same behavior).
Bug: opened menupopups do not have "open" or "aria-hidden" attributes
Status: NEW
Priority: --
Created: 2024-07-24 17:12:45+00:00
Resolved: 2024-07-24 17:16:37+00:00

The behaviour of `<menupopups>` differs on MacOS and Windows. On MacOS, opening a menupopup adds `aria-hidden="true" open="true"` attributes to the popup element. These attributes are not present on Windows.

A simple way to reproduce is to open the Browser Toolbox and observe the `contentAreaContextMenu` popup while right-clicking anywhere in the content area of the window.
Bug: New tab weather widget is stuck in "Weather data is not available" state for 5 minutes, if network is disconnected when you start Firefox
Status: NEW
Priority: --
Created: 2024-07-24 17:20:07+00:00
Resolved: 2024-08-23 12:13:46+00:00

STR:
1. Disconnect from the network.
2. Start Firefox such that it will load in a "Weather data is not available" state -- in my case, I deleted `activity-stream.weather_feed.json` and `cache2` from my Firefox user-profile folder before starting Firefox.
3. Open a new tab and observe the "Weather data is not available" UI.
4. Now, connect to the network, and be sure that Firefox can load e.g. https://example.org
5. Wait for the "Weather data is not available" UI" to change to show actual weather data. (Reload new-tab and/or open additional new-tabs in an attempt to nudge the widget to update.)

ACTUAL RESULTS:
* The weather widget is stuck in its "not available" state for 5 minutes, which feels like quite a long time.
* For this whole time, it shows an "alert" icon on every new-tab page that the user opens, which is a bit frustrating since it seems like Firefox is signaling something to the user about their connection being spotty, but there's nothing actually wrong and there's nothing the user can do about it.

EXPECTED RESULTS:
* Weather data should be populated sooner after I become connected to the network. (e.g. we should possibly watch for other network-availability signals, if we've got them (e.g. piggybacking on our captive-portal detection perhaps?), and/or poll more frequently when we're in this data-not-available state)
* Alternately, maybe we should just hide this widget entirely when we're in the data-not-available state? That would avoid it feeling like a [Something's broken!] badge that's plastered on the top-left of every new-tab page, drawing user attention/concern, for a substantial period of time.
* Or we could just remove the caution-sign icon from the widget -- that's part of what makes it draw attention and feel like a "Hey look over here, something's broken!" badge (which is confusing after the user has successfully reconnected and yet we're still showing this caution-sign icon)

Side note:
The STR (purging weather data/cache) might seem somewhat contrived, but I think this is likely to be something that users stumble on in various real-world scenarios. I've hit it when starting up my main Firefox session in the morning yesterday and today, for whatever reason (not sure why). And I imagine users would hit this if they happen to launch Firefox before they're connected to the network (when their previous cached weather data is stale).
Bug: Animation of vw doesn't respond to window resize
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-24 17:35:15+00:00
Resolved: 2024-07-24 17:50:37+00:00

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

Steps to reproduce:

Load the following url: data:text/html,<style>@keyframes x{to{width:50vw;}}</style><div style="animation:x both;background-color:black">test
Then resize the browser window


Actual results:

The black bar doesn't change size, but instead stays the same length it was at page load. 


Expected results:

The bar should scale with the browser window.
Bug: Crash in helper.exe on post update firewall setup
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-07-24 21:15:07+00:00
Resolved: 2024-08-26 20:38:34+00:00

For the last week or so on my Windows 10 machine (64-bit 10.0.19045), when Nightly updates on startup I have been getting the Just In Time Debugger popup informing me that helper.exe crashed. The command line is `C:\Program Files\Firefox Nightly\uninstall\helper.exe /PostUpdate`.

Digging into it today I saw that the crash is coming from [this line in the liteFirewall NSIS plugin](https://searchfox.org/mozilla-central/rev/79f37e7fcd8994d86b0c610a87af4ef0343166ee/other-licenses/nsis/Contrib/liteFirewall/liteFirewall.cpp#114), which is attempting to print an error result in an exception `catch` block. But this is a bug: It is trying to print the return value of [`_com_error::Error()`](https://learn.microsoft.com/en-us/cpp/cpp/com-error-error?view=msvc-170) as a string (`"%s"`), but it is really an `HRESULT`. This explains why the crash is attempting to read address 0x800401F3, which is `CO_E_CLASSSTRING`.

I don't see any recent changes to how the installer/post-update helper deal with the firewall config, though I haven't been paying close attention. It's likely that something recently changed on my machine to cause this error recovery path to be reached only now. My Update History shows two update failures (20200722214643 and 20240723211328, patch apply failed), but then there are also successful patches after those, so maybe my install is corrupted somehow. I don't recall making any firewall configuration changes recently, though there was a big Windows update not long before this started happening.

Please let me know if there's any more info I can provide or tests I should try before I blow away my Nightly install and firewall settings. I can provide the minidump from helper.exe if it would be useful.
Bug: Geko Min and Max version issue (every Firefox version)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-07-24 22:56:39+00:00
Resolved: 2024-08-08 12:09:17+00:00

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

Steps to reproduce:

Tryed to start Firefox


Actual results:

Crash with an error that Geko's MinVersion and MaxVersion is not compatible with version 129.0


Expected results:

Normal run.

Possible fix to resolve the issue:

From the "Geko":

* remove the MaxVersion check
* for the MinVersion set the value of the previous version number (for example, if the current version is 129.0, then the MinVersion should be at latest 127.0 or 128.00 for backwards compatibility.
Bug: cannot drag "about:preferences" text into new tab
Status: UNCONFIRMED
Priority: P5
Created: 2024-07-25 00:35:05+00:00
Resolved: 2024-08-06 14:42:02+00:00

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

Steps to reproduce:

1. select/hightlight the text "about:preferences" from any site (easiest would be to select the text inside the quotes on this very website)
2. drag this selection to the tab bar until you see the blue cursor for opening a new tab
3. release the text selection


Actual results:

nothing


Expected results:

a new tab should open and immediately navigate to about:preferences, the way dragging any other string of text onto the tab bar opens a new tab and either performs a search or navigates to that url
Bug: Backup with sensitive information doesn't work
Status: NEW
Priority: P3
Created: 2024-07-25 09:12:28+00:00
Resolved: 2024-08-14 08:43:44+00:00

**Found in**
* latest Nightly 130.0a1

**Affected versions**
* latest Nightly 130.0a1

**Tested platforms**
* Affected platforms: Windows 11, Ubuntu 22.04 and macOS 14

**Preconditions**
* `browser.backup.preferences.ui.enabled` = true 
* `browser.backup.scheduled.idle-threshold-seconds` = 5
* `browser.backup.scheduled.enabled` = true
* make sure the profile contains senstivie information, e.g. passwords, cookies, payment methods.

**Steps to reproduce**
1. Go to the backup section from "about:preferences" page.
3. Click on the "Back up your sensitive data" checbox, provide a pasword, then hit the "Save" button.
4. Leave the browser in idle mode, around 5 seconds. 
5. Click on the "Restore..." button from "Restore you data" section.
6. Choose the backup file, then restore it.

**Expected result**
* Backup file contains senstive information, e.g. passwords, cookies, payment methods.

**Actual result**
* Backup file does not contain senstive information, e.g. passwords, cookies, payment methods.

**Regression range**
* Not a regression.

**Additional notes**
Other issues tirggered by the fact that backing with sensitive information functionality does not work:
1. "Not encrypted" string appear in this backup page even though it was backed up with encryption.
2. "Back up with sensitive information data" checkbox remains unchecked after providing a password.
3. Backup section is not turned on after providing the password. (STR: `browser.backup.scheduled.enabled` set to false - Click on the "Manage backup" - Check the "Back your sensitive data" checbox -> Enter a passowrd -> Turn on backup).
Bug: If the location is changed for the backup file is changed a second folder with the same name is created, "Restore Firefox"
Status: NEW
Priority: P3
Created: 2024-07-25 09:51:43+00:00
Resolved: 2024-07-29 14:33:27+00:00

**Found in**
- latest Nightly 130.0a1

**Affected versions**
- latest Nightly 130.0a1

**Tested platforms**
- Affected platforms: Windows 11, Ubuntu 22.04 and macOS 13

**Preconditions**
- browser.backup.preferences.ui.enabled = true
- have a "Restore Firefox" folder previously saved. 

**Steps to reproduce**
1. Go to the backup section from "about:preferences" page.
2. Click on the "Manage backup" and turn on backup. 
3. Click on the "Edit..." button in order to change location. 
4. Select the "Restore Firefox" folder previously saved. 

**Expected result**
- The new location for the backup file is xxx/xxx/.../**Restore Firefox**. 

**Actual result**
- The new location for the backup file is xxx/xxx/.../**Restore Firefox/Restore Firefox**. 

**Regression range**
- Not a regression.

**Additional notes**
- This type of file selection is very confusing, because the user thinks that the first "Restore Firefox" folder is the one that was selected for the new location, instead a new folder with the same name is created.
Bug: Tabs without favicons don't look right in the vertical tabstrip
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-07-25 10:14:35+00:00
Resolved: 2024-09-19 14:46:23+00:00

STR:

1. open `data:text/html,` as a tab

ER:

Be able to see it (with a default favicon, probably) in the tabstrip

AR:

Blank space (though the hover effect shows something is there)

(I did search to see if this was on file already but didn't see anything - please dupe if this is already a known issue.)
Bug: Disable tab synchronization tests for Thunderbird
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-07-25 10:50:29+00:00
Resolved: 2024-07-26 04:02:17+00:00

The `test_commands_closetab.js` tests do not make sense for Thunderbird and recent test changes appear to have caused these tests to fail Thunderbird CI. The tests in question should be skipped when the Thunderbird test suite is run.
Bug: The backup file is not automatically detected in the "Restore your data" dialog
Status: NEW
Priority: P3
Created: 2024-07-25 11:40:50+00:00
Resolved: 2024-07-29 14:33:33+00:00

**Found in**
* latest Nightly 130.0a1

**Affected versions**
* latest Nightly 130.0a1

**Tested platforms**
* Affected platforms: Windows 11, Ubuntu 22.04 and macOS 14

**Preconditions**
* `browser.backup.preferences.ui.enabled` = true 
* `browser.backup.scheduled.idle-threshold-seconds` = 5
* `browser.backup.scheduled.enabled` = true

**Steps to reproduce**
1. Go to the backup section from "about:preferences" page.
2. Enable backup by clicking on the "Manage backup" -> "Turn on backup".
3. Wait for the backup file to be created.
4. Click on the "Restore..." buton from the "Restore your data" section.

**Expected result**
* The "Restore your data" dialog displays the backup file loaded from the specified backup file path.

**Actual result**
* The backup file is not automatically detected in the backup file dialog; it must be manually loaded first.

**Regression range**
* Not a regression.

**Additional notes**
- Based on my understanding of the Figma specifications, it appears that the backup file should be detected automatically. If it requires the user to manually select the file, we can consider closing this bug as invalid.
Bug: No error message is shown to the user in the "Restore your data" dialog if the backup file has been deleted
Status: NEW
Priority: P3
Created: 2024-07-25 12:06:16+00:00
Resolved: 2024-07-29 14:33:40+00:00

**Found in**
* latest Nightly 130.0a1

**Affected versions**
* latest Nightly 130.0a1

**Tested platforms**
* Affected platforms: Windows 11, Ubuntu 22.04 and macOS 14

**Preconditions**
* `browser.backup.preferences.ui.enabled` = true 
* `browser.backup.scheduled.idle-threshold-seconds` = 5
* `browser.backup.scheduled.enabled` = true

**Steps to reproduce**
1. Go to the backup section from "about:preferences" page.
2. Enable backup by clicking on the "Manage backup" -> "Turn on backup".
3. Wait for the backup file to be created.
4. Click on the "Restore..." buton from the "Restore your data" section.
5. Click on the "Browser..." buton, then select the backup file.
6. Delete the backup file from where it has been saved.
7. Click the "Restore and restart" button from the "Restore your data" dialog.

**Expected result**
* The "Restore your data" dialog displays an appropriate error message notifying the user that the file is missing.

**Actual result**
* The "Restore your data" dialog does not display any errors regarding the missing file.

**Regression range**
* Not a regression.