av9ash/GitBugs huggingface dataset:
Bug: Recently closed tabs behave oddly when navigated with arrow keys rather than tab keys
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-09-08 16:20:30+00:00
Resolved: 2023-06-02 15:23:39+00:00

I'm sure there's context I'm missing here, but it appears we have some incorrect semantics for the markup of the recent closed tabs in the "recently-closed-tabs-list".
Feel free to call out any incorrect assumptions or gaps!
1. The "closed-tab-li" list items should have `role="link"` instead of `role="button"` since we are navigating the user away from the current location when one of the recently closed tab items is activated.
2. The whole item should probably be an `<a>` instead of a focusable `<li>`, which is why we needed custom styles for its focus state to get rid of the blue-on-white outline (Bug 1786397). I think I get why an `<li>` was chosen though, trying to get the entire item to be highlighted on hover
  - If not the whole item, the link part should be an `<a>`, but that will change how the item gets focused and all that.

The current semantics are a bit confusing when using NVDA as well. Using tab to navigate each item works as expected but if you navigate via arrow keys, it's a bit odd (in my opinion). For example, if you recently closed wikipedia.org and went to your recently closed tabs list and focused the first item via tab, NVDA will announce the following: 
"Recently closed  region    clickable  list  with 1 items  Wikipedia, the free encyclopedia  en.wikipedia.org  Just now  button    Open https://en.wikipedia.org/wiki/Main_Page in a new tab" which is good. 

However, if I have a list with more than one item, I should be able to use the arrow keys to navigate this list. What happens instead is this from NVDA:
- I press the down arrow, NVDA announces "button    Wikipedia, the free encyclopedia"
- I press the down arrow again, NVDA announces "button    en.wikipedia.org"
- I press the down arrow a third time, NVDA announces "button 4 min. ago"

This behavior doesn't seem correct to me. I'm guessing because the `<li>` has role button, that this is being inherited by the child elements of each `<li>` in this recently closed list and causing each child element to be read independently from each other and also as buttons. Fixing the `role="button` would remedy part of this issue, but maybe reading each child element independently is expected with elements that are nested in a `<li>`

Maybe this should be split into multiple bugs, but it seems like we can make this list a bit more clear with some modifications and reduce some tech debt at the same time. Again, feel free to call out any incorrect assumptions or gaps in my knowledge!
Bug: “Tab pickup” option doesn’t show iOS device as connected to sync, after changing the password from it
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2022-09-08 16:20:59+00:00
Resolved: 2024-07-27 00:01:08+00:00

**Precondition**
* The user is connected to sync on desktop and on iOS device;

**Affected versions**
* 106.0a1 (2022-09-08)

**Tested platforms**
* Affected platforms: windows 10, macOS 10.14.6
* Unaffected platforms: Android 

**Steps to reproduce**
1. On the connected iOS device, access your Firefox account from the 3 dots menu;
2. Access the “Manage account & Devices” option;
3. From the Firefox account settings page, change the password;
4. The user is disconnected from the desktop sync, the iOS device is still connected to sync;
5. Reconnect to the desktop sync, with the new password;
6. Access the Firefox view tab;
7. Observe the “Tab pickup” option;

**Expected result**
* The 3 last active tabs are displayed in ”Tab pickup”  section;

**Actual result**
* The “Sync Firefox on your phone or tablet” title is displayed and the user is not seen as connected on the mobile device;

**Additional notes**
* This is not reproducible using Android devices since the “Manage account & Devices” option is not available in sync
* Signing out from the mobile device and then Signing in again, the 3 last active tabs are displayed in ”Tab pickup” section;
* Connecting the iOS device first to sync and then with the same account connecting on desktop, the 3 last active tabs are **not** displayed in ”Tab pickup” section;
* Connecting an Android device first to sync and then with the same account connecting on desktop, the 3 last active tabs **are** displayed in ”Tab pickup” section;
Bug: 9.16 - 8.6% tabswitch / tabswitch + 1 more (Linux) regression on Tue September 6 2022
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-08 16:25:49+00:00
Resolved: 2022-09-17 17:03:09+00:00

Perfherder has detected a talos performance regression from push [de5bd66dff7834e7eab425b7091f38140cc26ea9](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=de5bd66dff7834e7eab425b7091f38140cc26ea9). As author of one of the patches included in that push, we need your help to address this regression.

### Regressions:

| **Ratio** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--| 
| [9%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,4086186,1,1)  | [tabswitch](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tabswitch)  | linux1804-64-shippable-qr | e10s fission stylo webrender-sw | 6.93 -> 7.56 |
| [9%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,3869125,1,1)  | [tabswitch](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tabswitch)  | linux1804-64-shippable-qr | e10s fission stylo webrender | 6.95 -> 7.57 |
| [9%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,3869125,1,1)  | [tabswitch](https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#tabswitch)  | linux1804-64-shippable-qr | e10s fission stylo webrender | 6.98 -> 7.58 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=35337), including links to graphs and comparisons for each of the affected tests. Please follow our [guide to handling regression bugs](https://wiki.mozilla.org/TestEngineering/Performance/Handling_regression_bugs) and **let us know your plans within 3 business days, or the offending patch(es) may be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).
Bug: Firefox View "Tab Pickup" section is stuck in "Sit tight while your tabs sync. It’ll be just a moment."
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-09-08 16:55:09+00:00
Resolved: 2022-09-22 16:30:04+00:00

I unfortunately don't have STR; but I just noticed that the Firefox View page in all of my Firefox windows on my linux laptop are currently showing:
`Sit tight while your tabs sync. It’ll be just a moment.`
...and have been showing it for about 10 minutes.  (I noticed it 10 minutes ago and it's still like that.)

Meanwhile `about:sync-log` shows that I had a successful sync 11 minutes ago (from 1 minute before I thought to check Firefox View and noticed this issue).

 Also, `History | Synced Tabs` shows me a nice list of up-to-date synced tabs.

Nothing particularly interesting shows up in browser console or in web console for my Firefox View tabs.  New windows & new `about:firefoxview` tabs show this issue as well.

So it looks like there's some sort of mismatch where Firefox View mistakenly thinks that we're syncing but in fact we're not. (?)
Bug: Intermittent browser/components/preferences/tests/browser_searchRestoreDefaults.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-09-08 17:28:41+00:00
Resolved: 2022-12-20 17:03:05+00:00

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

---
```
[task 2022-09-08T16:08:17.335Z] 16:08:17     INFO - TEST-PASS | browser/components/preferences/tests/browser_searchRestoreDefaults.js | All engines are restored - 10 == 10 - 
[task 2022-09-08T16:08:17.335Z] 16:08:17     INFO - Leaving test bound test_removeOutOfOrder
[task 2022-09-08T16:08:17.336Z] 16:08:17     INFO - Buffered messages finished
[task 2022-09-08T16:08:17.337Z] 16:08:17     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_searchRestoreDefaults.js | waiting for vsync to be disabled - timed out after 50 tries. - false == true - JS frame :: chrome://mochikit/content/browser-test.js :: ensureVsyncDisabled :: line 575
[task 2022-09-08T16:08:17.337Z] 16:08:17     INFO - Stack trace:
[task 2022-09-08T16:08:17.337Z] 16:08:17     INFO - chrome://mochikit/content/browser-test.js:ensureVsyncDisabled:575
[task 2022-09-08T16:08:17.338Z] 16:08:17     INFO - Not taking screenshot here: see the one that was previously logged
[task 2022-09-08T16:08:17.339Z] 16:08:17     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_searchRestoreDefaults.js | vsync remained enabled at the end of the test. Is there an animation still running? Consider talking to the performance team for tips to solve this. - false == true - JS frame :: chrome://mochikit/content/browser-test.js :: ensureVsyncDisabled :: line 576
[task 2022-09-08T16:08:17.339Z] 16:08:17     INFO - Stack trace:
[task 2022-09-08T16:08:17.339Z] 16:08:17     INFO - chrome://mochikit/content/browser-test.js:ensureVsyncDisabled:576
[task 2022-09-08T16:08:17.340Z] 16:08:17     INFO - GECKO(2340) | MEMORY STAT | vsize 1705MB | vsizeMaxContiguous 17MB | residentFast 859MB | heapAllocated 539MB
[task 2022-09-08T16:08:17.340Z] 16:08:17     INFO - TEST-OK | browser/components/preferences/tests/browser_searchRestoreDefaults.js | took 9416ms
```
Bug: Fix the margins for window modal onboarding dialogs
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-09-08 18:16:30+00:00
Resolved: 2022-09-10 21:57:18+00:00

(See attached screenshot)

In bug 1786509 we fixed some issues affecting the sizing and scrollbars of spotlight modals. Initially we fixed this issue (see [this revision](https://phabricator.services.mozilla.com/D156127?id=624156) for the relevant changes), but bug 1789008 changed our MR spotlights from window modals to tab modals.

We then narrowed the changes to just apply to tab modals, to avoid potentially breaking the wide variety of window modals. But in the long term it would be good to fix the window modals too. So, I will revisit this when the work on MR dialogs is finished.
Bug: The Tags expander button in the Library window is not aligned with its textbox
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-09-08 21:35:48+00:00
Resolved: 2023-04-20 13:43:30+00:00

It's because of this `stretch` here:
https://searchfox.org/mozilla-central/rev/685203e4bc211073284f3c36f7f3d34f0953bb9c/browser/components/places/content/editBookmarkPanel.inc.xhtml#77
That file is shared with both the Library and the Edit Bookmark panel, and a change to one won't necessarily work for the other.

`-moz-box-align: center !important;` on the same hbox doesn't help.
Bug: Firefox consistently crashing on many pages (reproducible)
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-09-08 22:38:00+00:00
Resolved: 2022-10-04 15:06:02+00:00

Firefox 104 crashes on several pages. The crash always happens while the page is rendering/loading. After reloading the page crashes again at the same point.
An example:
https://hackaday.com/2021/07/13/muse-group-continues-tone-deaf-handling-of-audacity/

Running Arch Linux with Openbox
amdgpu as display driver on xorg

System is up to date except for wxwidgets.
Bug: [foxfooding] The Firefox View icon (the Nightly logo) "dims" when something else is the focus window on your desktop
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2022-09-08 22:50:50+00:00
Resolved: 2023-11-07 22:07:29+00:00

**Firefox Version:** Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36
**Window Size (inner width and height):** 1920x919
**GitHub Username:** @lime124
## Steps to Reproduce
The firefox view icon (the nightly logo) "dims" when something else is the focus window on your desktop. so for example, zoom in the third screenshot is the focus thing and the other two firefox windows are not. the firefox view icon is dimmed. but when the window is in focus the firefox view icon is "not dimmed". it's weird b/c the other tab icons don't do that. all the pinned tabs i have and all the open tabs, none of them dim when it's not in focus.

## Expected Behavior
The logo doesn't dim; same as the other favicons.

## Actual Behavior
The logo dims unexpectedly.

## Attachment
![Attachment](https://mk-mozilla-campaign-form.s3.eu-central-1.amazonaws.com/707a3792-9a79-43a2-9088-376397722009.png)
[Link to the original attachment](https://mk-mozilla-campaign-form.s3.eu-central-1.amazonaws.com/707a3792-9a79-43a2-9088-376397722009.png)
Bug: Firefox installer will happily overwrite Firefox Beta when running
Status: NEW
Priority: P3
Created: 2022-09-08 23:18:13+00:00
Resolved: 2022-09-29 14:04:16+00:00

Steps to reproduce:

1. Install Firefox Beta.
2. Run it.
3. Now run the default installer for release (the one that comes as Firefox Installer.exe)
4. It will install, and fail to run Firefox complaining about a running session
5. Your existing session will work... until it runs out of preallocated processes and chokes up without an error.

This doesn't seem beta or release specific and is just something the default installer does. When you use the version specific 'old' installers (i.e. Firefox Setup <blah>.exe) this does not happen as it refuses to install while you have a session running.

Expected behaviors:

1. Installer should refuse to install while an existing session is running from the default install dir.
2. Existing session should suggest a restart when a version mismatch does somehow occur.
3. Perhaps Beta should install itself in a different directory than Program Files\Mozilla Firefox
Bug: The "Private Window" shortcut is no longer pinned to the taskbar
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-09-09 07:36:22+00:00
Resolved: 2022-09-15 08:31:50+00:00

**[Notes]:**
- This issue is reproducible if the "Pin Private Window" action is taken from the existing Onboarding modals.

**[Affected versions]:**
- Firefox Nightly 106.0a1 - Build ID: 20220908213354

**[Affected Platforms]:**
- Windows 10 x64

**[Prerequisites]:**
- The "Private Window" shortcut is not pinned to the taskbar.

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Open a new "Private Window".
3. Click the "Pin to taskbar" button and observe the behavior.

**[Expected result]:**
- The "Private Window" shortcut is pinned to the taskbar.

**[Actual result]:**
- The "Private Window" shortcut is NOT pinned to the taskbar and the following error is displayed in the "Browser Console":

`[Exception... "Failure"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "<unknown>"  data: no] ShellService.jsm:460
    pinToTaskbar resource:///modules/ShellService.jsm:460
    AsyncFunctionThrow self-hosted:885`

**[Regression Window]:**
- Considering that this issue is not reproducible with the Firefox Nightly build from 09/07/2022 using the Mozregression tool I have managed to find the following regression window:
Last good revision: bea1e1ba4a14e676e4ebefa371d8fb5fea9d6001
First bad revision: b1462bbc7934f45eff16184644a1eaca75b044c0
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=bea1e1ba4a14e676e4ebefa371d8fb5fea9d6001&tochange=b1462bbc7934f45eff16184644a1eaca75b044c0

From the pushlog it seems that Bug 1782295 may have caused this regression.

@Ben, could you please take a look over this issue?

**[Additional Notes]:**
- This issue is not reproducible with the regular "Firefox" shortcut.
- Attached a screen recording of the issue.
Bug: Restoring a window doesn't always preserve the containers setup
Status: UNCONFIRMED
Priority: --
Created: 2022-09-09 07:48:37+00:00
Resolved: 2022-11-15 08:16:13+00:00

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

Steps to reproduce:

I know there is this bug report: 1193854. But I'm still facing a similar issue with Firefox 9x and 10x on macOS.

I use Firefox for work, and in this case, I have a window dedicated to my work tabs, all of them open in a dedicated container for work.

At the end of my work day, I close the window...Firefox stays generally open with 2 other windows, one in private mode with few tabs, and one for my personal tabs open in personal container.

When I begin my work day, I open the closed work window through the History -> Recently closed windows.


Actual results:

I didn't find a perfect reproduction scenario, but often when I restore my work window, some tabs are open in the correct work container while other are not. This work window is made of between 10 and 15 tabs. 

As those tabs are used for web apps (Google Suite, Notion, etc), so dependent on credentials and login, it's pretty annoying because I've to open specifically each tab in the correct container, and close the bad ones.

I've some tech skills, so I can try to investigate a bit, but I don't really know the Firefox internals. Any advice or guidance could help to analyse further.


Expected results:

All tabs should be open in the correct container.
Bug: Tab strip displays the "Open in a new tab" animation outside the browser window in Arabic builds
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-09-09 08:01:58+00:00
Resolved: 2022-10-21 07:55:11+00:00

**Affected versions**
* 106.0a1

**Tested platforms**
* Affected platforms: macOS12 , Windows 10, Win11
* Unaffected platforms: Ubuntu 22

**Steps to reproduce**
1. Launch FF (Arabic build)
2. Open multiple tabs
3. Open wikipedia.org
4. Click the Firefox View button
5. Go back to wikipedia page
6. Select any link from the wikipedia homepage and drag it to the tab strip

**Expected result**
* The tab strip displays the animation for a new opened tab at the end of the tab carousel.

**Actual result**
* The tab strip displays the animation for a new opened tab outside the browser window.

**Additional notes**
* This issue occurs in the Arabic build.
* This issue does not happen if the user removes the Firefox View button from the tab strip (via Customize or by disabling the FF View pref) 
* This issue does not occur for Ubuntu 22.
* This issue occurs in the latest 105.0b9 beta build as well (if activating the FF View pref)
Bug: Wrong fonts in Firefox Nightly
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-09 08:11:56+00:00
Resolved: 2022-09-09 10:12:22+00:00

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

Steps to reproduce:

Sorry if it's some of my doings, but I don't remember to do anything in particular. Fonts just suddenly changed.
Everything is normal in Firefox Developer Edition.


Actual results:

I use system (dark) theme. And on some sites text is just unreadable. For example, Asana, Telegram Web Z. And even on bugzilla.
Fonts on this page are just wrong https://rust-osdev.com/this-month/2022-08/
See attach.


Expected results:

On attached images you can see the difference between Nightly and Developer Edition.
Bug: The  “Sync services are down, firewall or similar blocking specific connections” error state can’t be triggered on Linux and macOS
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-09-09 08:19:41+00:00
Resolved: 2022-10-21 11:00:30+00:00

**Precondition**
* The user is connected to sync on desktop and on a mobile device;

**Affected versions**
* 106.0a1 (2022-09-08)

**Tested platforms**
* Affected platforms: Ubuntu 22.04, macOS 10.14.6 
* Unaffected platforms: windows 10

**Steps to reproduce**
1. Be in the Firefox view tab;
2. From a connected mobile device, change the account password via Sync;
3. Observe the “Tab pickup” section;

**Expected result**
* "We’re having trouble syncing/ Firefox can’t reach the syncing service right now./ Try again in a few moments." error message is displayed with "Try again" blue button.;

**Actual result**
* The “Switch seamlessly between devices” title and “Continue” button is displayed in the “Tab pickup”  section;

**Additional notes**
* Might be related to this issue [1789876](https://bugzilla.mozilla.org/show_bug.cgi?id=1789876)
Bug: Sign Up for data breaches brings to a "Protentional Security Risk" page
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-09-09 08:52:13+00:00
Resolved: 2023-01-09 14:32:49+00:00

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

Steps to reproduce:

- Open about:protections
- Click on "Sign Up for Breach Alerts"



Actual results:

- https://monitor.firefox.com/?entrypoint=protection_report_monitor&utm_source=about-protections doesn't opens, but a warning page: "Warning: Potential Security Risk Ahead"


Expected results:

The requested page opens correctly.
Bug: [Locale] The name is not translated if PBM icon is pinned to taskbar
Status: RESOLVED
Priority: P2
Resolution: INVALID
Created: 2022-09-09 08:55:45+00:00
Resolved: 2022-10-12 15:11:12+00:00

**Found in**
* Nightly 106.0a1

**Affected versions**
* Nightly 106.0a1
* Firefox 105.0b9

**Tested platforms**
* Affected platforms: Windows 10, Windows 7
* Unaffected platforms: macOS, Ubuntu

**Precondotion**
* Make sure that the "Never" option is set for Combine taskbar buttons (Personalize -> Taskbar Settings).

**Steps to reproduce**
1. Download a locale build (FR for example).
2. Open Firefox and pin Private Browser icon to taskbar. 
3. Observe the name. 

**Expected result**
* The name is translated to French. 

**Actual result**
* The name is still in English. 

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

**Notes**
* If the icon is pinned to Start menu, the name is translated to French.
Bug: Two Firefox Private icons are displayed on All Programs menu.
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-09-09 09:31:25+00:00
Resolved: 2022-09-21 08:43:11+00:00

**Note**
*Issue reproduces only on Win7

**Found in**
* 106.0a1(20220908213354)

**Affected versions**
* 106.0a1(20220908213354)

**Tested platforms**
* Affected platforms:Win7
* Unaffected platforms: Win10, Ubuntu, Mac

**Steps to reproduce**
1. Uninstall all existing Firefox builds, delete all profiles and registry.
2. Do a Nightly clean install with the latest build.
3. Check all Firefox icons from Start - All Programs menu.

**Expected result**
* Only one Private icon for Firefox should be displayed.

**Actual result**
* There are two Private icons for Firefox on All programs.

**Regression range**
* First bad build: we saw the issue starting with build 106.0a1(20220908213354)

**Additional notes**
* Issue also reproducing for localizations (French-confirmed) and only on Win7.
Bug: [Colorway Closet] The previewed colorway is applied after a browser crash instead of the colorway already set
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-09-09 10:16:55+00:00
Resolved: 2022-09-09 14:07:19+00:00

#### Found in

Firefox 106.0a1

#### Affected versions

106.0a1

#### Tested platforms

macOS 11.6
Windows 10
Windows 11
Ubuntu 20

#### Preconditions
In about:config set:
"browser.theme.colorway-closet" to true
"browser.tabs.firefox-view" to true

#### Steps to reproduce

   1. Open Colorways modal from Fxview or from about:addons and set a colorway.
   2. Preview another colorway and without applying it, crash the browser.

#### Expected result
The colorway set in step 1 should remain applied after restoring the browser.

#### Actual result
The colorway previewed in step 2 before the browser crash is applied.

#### Regression range
Not a regression.