av9ash/GitBugs huggingface dataset:
Bug: Alt+enter on a switch-to-tab result doesn't open a new tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-05 17:24:15+00:00
Resolved: 2022-09-08 08:57:25+00:00

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

Steps to reproduce:

Win10 + FF x64 104.0.1, confirmed on a clean profile.

* Open 2 tabs, A & B.
* Focus the A tab.
* Go to the address bar & type some words that will cause FF to suggest the B tab, with the "Switch to tab" badge on the suggestion.
* Select the suggestion & press Alt+Enter


Actual results:

The URL from the suggestion opens in a new tab (just as a non-suggestion would).


Expected results:

The URL from the suggestion opens in the current tab (the A tab).
Bug: Password import not working on Firefox 104.0.1 on Linux, Mac and Windows
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-05 17:55:53+00:00
Resolved: 2022-10-19 17:59:46+00:00

Steps to reproduce:

I was trying to import passwords from a csv file to FireFox 104.0.1 on Arch Linux after a clean install of Arch Linux.


Actual results:

I enabled the signon.management.page.fileImport.enabled like usual and the "Import from a file" option was appeared in the Password Manager but after choosing the csv file, no password was imported to Firefox, no errors no any feedback from FireFox. I also tried on a Macbook Pro and a Windows 10 laptop but I faced the same problem, in the end I downloaded FireFox 103, the importing succeed.
Bug: Padding/space between Firefox View's divider and the tabstrip is 2px too wide (6px instead of expected 4px)
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-09-05 18:32:26+00:00
Resolved: 2022-09-12 11:42:31+00:00

Nightly 106.0a1 (2022-09-04) (64-Bit)
macOS 12.5.1

STR:

1.) Open a new window
2.) Hover over the Firefox-View button on the Tabstrip
3.) Take a look at the padding/space between the divider

Actual: It is 6px
Expected: It should be 4px. Same like the padding between tabs.

Screenshots are a attchaed.

Thanks.
Bug: The show/hide "twisty" button jumps out from under your mouse, on Firefox View "Recently Closed" section
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-09-05 22:07:55+00:00
Resolved: 2022-09-21 09:16:54+00:00

STR:
1. Open Firefox View.
2. Click the show/hide button to the right of "recently closed" (which initially looks like a `^`)

ACTUAL RESULTS:
The button jumps out from under your mouse, and in fact the whole section (including the title) jumps downwards to a new position, for no obvious reason/benefit.

EXPECTED RESULT:
- Buttons shouldn't move when you click them.
- This section shouldn't change positions when it's opened/collapsed.
Bug: Intermittent browser/components/sessionstore/test/browser_unrestored_crashedTabs.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-09-06 00:42:08+00:00
Resolved: 2023-11-22 12:00:41+00:00

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

---
```
[task 2022-09-05T23:58:32.521Z] 23:58:32     INFO - TEST-START | browser/components/sessionstore/test/browser_unrestored_crashedTabs.js
[task 2022-09-05T23:59:17.596Z] 23:59:17     INFO - TEST-INFO | started process screencapture
[task 2022-09-05T23:59:17.735Z] 23:59:17     INFO - TEST-INFO | screencapture: exit 0
[task 2022-09-05T23:59:17.735Z] 23:59:17     INFO - Buffered messages logged at 23:58:32
[task 2022-09-05T23:59:17.735Z] 23:59:17     INFO - Entering test bound test
[task 2022-09-05T23:59:17.735Z] 23:59:17     INFO - Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "data:text/html,<html><body>A%20regular,%20everyday,%20normal%20page." line: 0}]
[task 2022-09-05T23:59:17.735Z] 23:59:17     INFO - Buffered messages finished
[task 2022-09-05T23:59:17.735Z] 23:59:17     INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_unrestored_crashedTabs.js | Test timed out - 
[task 2022-09-05T23:59:17.736Z] 23:59:17     INFO - GECKO(5500) | MEMORY STAT | vsize 402841MB | residentFast 683MB | heapAllocated 153MB
[task 2022-09-05T23:59:17.736Z] 23:59:17     INFO - TEST-OK | browser/components/sessionstore/test/browser_unrestored_crashedTabs.js | took 45084ms
[task 2022-09-05T23:59:17.736Z] 23:59:17     INFO - Not taking screenshot here: see the one that was previously logged
[task 2022-09-05T23:59:17.736Z] 23:59:17     INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_unrestored_crashedTabs.js | Found a tab after previous test timed out: data:text/html,<html><body>A%20regular,%20everyday,%20normal%20page. - 
[task 2022-09-05T23:59:17.736Z] 23:59:17     INFO - checking window state
[task 2022-09-05T23:59:17.736Z] 23:59:17     INFO - TEST-START | browser/components/sessionstore/test/browser_upgrade_backup.js
```
Bug: Transparent <iframe> ends up with bright white background since Commit 495ffb27
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-06 02:56:44+00:00
Resolved: 2022-09-08 22:39:55+00:00

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

Steps to reproduce:

// transparent.html
<!DOCTYPE html>
<html>
	<head>
		<title>THIS SHOULD BE TRANSPARENT ONLY</title>
		<style>
			* {
				background: transparent;
			}
		</style>
	</head>
	<body>
		<h1>Hello World</h1>
	</body>
</html>

// red.html
<!DOCTYPE html>
<html>
	<head>
		<title>THIS SHOULD BE RED ONLY</title>
		<style>
			html, body {
				background: red;
			}

			iframe {
				background: transparent;
			}
		</style>
	</head>
	<body>
		<iframe src="transparent.html" allowtransparency="true"></iframe>
	</body>
</html>


Actual results:

The transparent <iframe> has a white background.


Expected results:

The transparent <iframe> should have no background.
Bug: SyncedTabs always prompts to unlock the primary password
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-06 03:18:37+00:00
Resolved: 2022-09-30 06:35:39+00:00

When a primary password is enabled, it is expected that Sync will cause prompt to be shown as the browser starts, and it's also expected a prompt will be shown each time the user selects "Sync Now".

However, it's not expected that any interaction with "sync tabs" (such as showing the "account" submenu) will cause a prompt to be shown - but it does.

Attaching a patch that ensures we only attempt to sync tabs when the login state is "ok" - other login related errors (such as an FxA auth error, or that the primary password is locked) causes us to decline syncing.

Automated testing for this is difficult as none of our tests use a real sync status, so the best we could do is mock sync to pretend to be in the very state we are explicitly testing for, but that doesn't seem particularly valuable.

I believe this will largely fix bug 1787619. WWe might need some followup so that the UI can show something appropriate when in this state, but this patch should not regress anything - all UI will show the same state now as when the user cancelled the main prompt.
Bug: On macOS, cmd+shift+T shortcut doesn't work if the browser is closed and then reopened
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-06 12:23:02+00:00
Resolved: 2023-02-14 23:39:33+00:00

**Found in**
- Nightly 106.0a1

**Affected versions**
- Nightly 106.0a1
- Firefox 105.0b7

**Tested platforms**
- macOS 12

**Affected platforms**
- macOS 12

**Unaffected platforms**
- Windows
- Linux 

**Preconditions**
- Have "Open previous windows and tabs" checked in about:preferences.

**Steps to reproduce**
1. Launch Firefox.
2. Open a few tabs/websites.
3. Select all the tabs using the "Command" key and close them via context menu.(Right click on any of the tabs and select "Close x tabs".
4. Re-launch Firefox.
5. Hit "Command"(⌘)+"Shift"(⇧)+"T".

**Expected result**
- All the closed tabs should be restored.

**Actual result**
- Nothing happens. 

**Regression range**
- Not a recent regression, Firefox 60 is also affected, will do some digging for a regression as soon as possible.

**Additional notes**
- On Windows and Linux the shortcut restores the previously closed tabs after re-launching the browser.
- On Chrome, tabs are restored one by one if the browser is re-launched.
- This shortcut works if the user doesn't close the browser. If one leaves 1 tab open and closes 4 others, the other 4 tabs are restored.
Bug: 0.24 - 0.08% installer size / installer size + 2 more (OSX) regression on Wed August 31 2022
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-09-06 14:58:01+00:00
Resolved: 2023-03-03 21:08:20+00:00

Perfherder has detected a build_metrics performance regression from push [ca8f3afc33914e9c8fd705ee80ca82394bccc550](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=ca8f3afc33914e9c8fd705ee80ca82394bccc550). 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)**| 
|--|--|--|--|--| 
| [0.24%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,2922314,1,2)  | installer size  | osx-aarch64-shippable | aarch64 nightly | 82,514,564.75 -> 82,714,206.00 |
| [0.23%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,2259234,1,2)  | installer size  | osx-shippable | instrumented | 121,416,721.25 -> 121,692,425.25 |
| [0.23%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,1921012,1,2)  | installer size  | osx-shippable | nightly | 84,907,690.75 -> 85,107,073.75 |
| [0.08%](https://treeherder.mozilla.org/perfherder/graphs?timerange=1209600&series=autoland,2259234,1,2)  | installer size  | osx-shippable | instrumented | 121,577,961.75 -> 121,671,659.33 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=35289), 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/).

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).
Bug: Wrong shell command when installed through Microsoft store
Status: NEW
Priority: P3
Created: 2022-09-06 19:26:50+00:00
Resolved: 2022-10-28 13:48:10+00:00

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

Steps to reproduce:

Install Firefox through Microsoft Store.
Set it as default Browser.


Actual results:

It creates registry
HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice - progId

HKEY_CLASSES_ROOT\{progId}\shell\open\command

But the command is like:
C:\Program Files\WindowsApps\Mozilla.Firefox_104.0.2.0_x64__n80bbvh6b1yt2\VFS\ProgramFiles\Firefox Package Root\firefox.exe -osint -url "%1"
There are missing quotes aorund the firefox.exe path.
                        "ProgId


Expected results:

The registry should have
"C:\Program Files\WindowsApps\Mozilla.Firefox_104.0.2.0_x64__n80bbvh6b1yt2\VFS\ProgramFiles\Firefox Package Root\firefox.exe" -osint -url "%1"
the path with quotes like when it is installed from the .exe from firefox website.
Bug: Multi-Account Container will not sync
Status: RESOLVED
Priority: P2
Resolution: WONTFIX
Created: 2022-09-06 19:28:35+00:00
Resolved: 2024-03-11 15:17:04+00:00

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

Steps to reproduce:

I am not sure if this is reproducable by others, however, for my Firefox account, I CAN sync Bookmarks across multiple devices. I can't sync Multi-Account Container changes.

Two weeks ago, changes that I made were not synced and now no changes are synced no matter what device I am using. This happens on a new profile or even on a clean VM with Firefox installed.

1) Create Firefox profile
2) Log into Firefox Account
3) Set up Multi Account Containers
4) Old, unchanged data syncs
5) Make changes on this device or any other and sync
6) Changes do not sync


Actual results:

No changes come in, just an old set up data from 2-3 weeks ago.


Expected results:

Container alternations should have synced.

These are some sync logs from 3 devices, I hope that this is helpful: 
https://1drv.ms/u/s!Ar5Vx9Edw8DmgZ5-r9GHrMoCazaHsg?e=SrcPdR
Bug: Emoji at the end of a filename or a directory name is treated as invalid character when downloading
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-06 20:19:43+00:00
Resolved: 2022-10-11 07:54:08+00:00

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

Steps to reproduce:

In a WebExtensions Add-on,
download a file by downloads.download() with a filename which ends with emoji such as 😀.

```
browser.downloads.download({
...
filename: 'path/to/a😀',
})
```

A directory name which ends with emoji also cause the problem.

```
browser.downloads.download({
...
filename: 'path/a😀/a.txt',
})
```
The probrem does not occur with a filename with a suffix such as `a😀.txt`.


Actual results:

downloads.download() rejects trailing emoji characters and throws an exception:
Error: filename must not contain illegal characters


Expected results:

downloads.download() accepts the specified filename and saves the file as the specified filename.
Bug: Many existing users w/o session restore MAY be left with extra home/newtab/blank tab after onboarding experience
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2022-09-06 20:30:17+00:00
Resolved: 2022-10-10 17:48:55+00:00

Ed did some testing on this today and it looks fairly likely that there won’t be a problem here (see the Slack thread for the gory details of that).  To really be sure, we’ll need some higher fidelity testing.  Here’s an approximate list of steps, including commentary on stuff that needs fleshing out:

* Install a Fx 105 nightly build (each time you do this test requires a new install, as the previous one will have upgraded your 105 to 106)
  * https://ftp.mozilla.org/pub/firefox/nightly/2022/08/2022-08-18-06-57-02-mozilla-central/
* Create a new profile
* Quit & Start up again
    * this better simulates normal usage by clearing out some “new profile stuff”

* Verify that there is a single open tab
* Decline the offer to open previous tabs
* Open a web page (eg wikipedia.org) in the existing tab

Simulate the conditions described in https://bugzilla.mozilla.org/show_bug.cgi?id=1774071#c3
* In about:config,
* set `browser.startup.homepage_override.mstone` to 105
* XXX How to simulate WhatsNew page being gone
* create `browser.startup.upgradeDialog.version` as a Number preference
  * set it to 105


Figure out how to trigger an update download such that the “Restart needed” prompt in the upper right corner of the screen drops down.  This is to try and best simulate the real typical user experience in terms of what gets automatically restored after a restart.  
* `Cc["@mozilla.org/updates/update-service;1"].getService(Ci.nsIApplicationUpdateService).checkForBackgroundUpdates()` did not do the trick for me, though I was hopeful.
* Possible fallbacks, possibly less good simulations of user experience, but...
  * Wait for the green in the Hamburger menu that signifies that an update is available
     * click the Hamburger menu
     * click upgrade and restart
  * Go to Firefox -> About Firefox (on Mac; I think this can be reached from the Hamburger > Help menu on Windows)
     * allow it to download the 106 nightly update
  * Click the “restart" button.

Finally:

* The first tab _may_ be about:home, and if so, it’s the bug I’m talking about
* If we’ve found the right prefs to tweak as described above, verify that there is NOT a “What’s new with Firefox” tab present
* Verify that there is another about:home tab to the right of that with upgrade modal dialog
** If for some reason this doesn't work, we can mostly simulate with by entering `Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._showUpgradeDialog()` from the Browser Toolbox,
* an additional 'about:home' page should appear, with the upgrade onboarding modal on top of it
* go through the modal screens, and on the last one, click "Start browsing"
* browsing should start in the tab that the modal was in, leaving a single, unused about:home tab to the left.  If this is true, it’s definite confirmation of the potential bug here.
Bug: When opening a new window with a custom new window URL configured, the address bar is focused instead of the page.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-09-07 00:12:36+00:00
Resolved: 2022-09-12 12:28:39+00:00

Steps to reproduce:

1.  Have a custom home page URL configured.
2.  Open a new window.


Actual results:

The address bar is immediately focused.

---

This is a problem for multiple reasons:

1.  For websites where there is a text field that is automatically focused (e.g. shipping tracking sites, internal company search engines, Wikipedia, etc...), if they are set as the default Home Page, then the user clearly wants that site functionality.  Having the focus default to the address bar breaks that functionality and forces the user to have to click within the page instead of being able to just start typing.

2.  For websites that do not have a text field that is automatically focused (e.g. news sites), the user will want to be able to simply hit the arrow or page down keys in order to start browsing - but again, if the focus is defaulting to the address bar, they won't be able to without extra effort.

If this is a deliberate change, then it is imperative that Firefox have a way to configure it back to the old behavior to leave the focus on the site itself.

---



Expected results:

The focus should have stayed on the page itself.
Bug: [Quickactions]Typing a space as a first character displays all quickaction buttons
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-07 10:11:06+00:00
Resolved: 2023-06-15 11:50:57+00:00

**Found in**
* Fx106.0a1

**Affected versions**
* Fx106.0a1

**Affected platforms**
* Windows 10
* Ubuntu 22.04
* macOS

**Steps to reproduce**
1. Launch Firefox.
2. Click the address bar.
3. Type ' ' (a blank space).

**Expected result**
* nothing changes in the address bar drop-down.

**Actual result**
* All the quickaction buttons are displayed.

**Regression range**
* Not a regression.
Bug: [Colorway Closet] The success checkmark is misaligned with the "Make Firefox Home your colorful homepage" text
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-09-07 12:29:54+00:00
Resolved: 2022-10-07 21:09:12+00:00

**Found in**
* Firefox 106.0a1 

**Affected versions**
* Firefox 106.0a1  

**Affected platforms**
* Windows 10 x64
* Windows 11 x64
* Ubuntu 20.04 x64
* macOS 11.6

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

**Steps to reproduce**
1. Set a custom home page in about:preferences
2. Open Colorways modal from Fxview or from about:addons and click on the Apply button.

**Expected result**
The success checkmark should be aligned with the "Make Firefox Home your colorful homepage" text.

**Actual result**
The success checkmark is misaligned with the "Make Firefox Home your colorful homepage" text.

**Regression range**
Not a regression.
Bug: [Quickactions] NVDA screen reader doesn't read the help button properly
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-07 12:50:11+00:00
Resolved: 2023-06-15 11:50:57+00:00

**Found in**
* Fx 106.0a1

**Affected versions**
* Fx 106.0a1

**Affected platforms**
* Windows 10

**Steps to reproduce**
1. launch NVDA.
2. Launch Firefox.
3. Click the address bar.
4. Using the keyboard, navigate to the quickactions help button.

**Expected result**
* NVDA reads 'help button' when the button is reached.

**Actual result**
* NVDA reads 'button'.

**Regression range**
* Not a regression.

**Additional notes**
* Please note that the button is not read out on mouse over like the rest of the quickaction buttons. This particular issues seems similar to the issue we have on intervention cards in bug 1625254.
Bug: [Quickactions] Actions should be visible when using `>`, even if "Quick actions" is not enabled in preferences
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-09-07 13:46:03+00:00
Resolved: 2022-10-10 13:05:49+00:00

STR

1. Disable `Quick actions` via Preferences --> Address Bar
2. Confirm that actions are no longer visible in the address bar's dropdown
3. Type `>` to start searching for actions

Expected

- address bar switched to searching for actions
- a filtered list of available actions 

Actual

- address bar switched to searching for actions
- no actions are listed

Notes

- `browser.urlbar.suggest.quickactions` is `false`
- `browser.urlbar.shortcuts.quickactions` is `true`
Bug: Intermittent browser/base/content/test/general/browser_newwindow_focus.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-09-07 13:46:28+00:00
Resolved: 2022-10-04 17:01:47+00:00

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

---
```
[task 2022-09-07T12:14:06.985Z] 12:14:06     INFO - TEST-PASS | browser/base/content/test/general/browser_newwindow_focus.js | URLBar should be focused - {} == {} - 
[task 2022-09-07T12:14:06.985Z] 12:14:06     INFO - Buffered messages logged at 12:14:01
[task 2022-09-07T12:14:06.986Z] 12:14:06     INFO - Leaving test bound test_no_steal_focus
[task 2022-09-07T12:14:06.986Z] 12:14:06     INFO - Console message: [JavaScript Warning: "Storage access automatically granted for origin �moz-nullprincipal:{6c74fd4b-6a41-47bd-a01a-b332855d60ca}� on �null�."]
[task 2022-09-07T12:14:06.987Z] 12:14:06     INFO - Buffered messages finished
[task 2022-09-07T12:14:06.987Z] 12:14:06     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_newwindow_focus.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-07T12:14:06.987Z] 12:14:06     INFO - Stack trace:
[task 2022-09-07T12:14:06.988Z] 12:14:06     INFO - chrome://mochikit/content/browser-test.js:ensureVsyncDisabled:575
[task 2022-09-07T12:14:06.988Z] 12:14:06     INFO - Not taking screenshot here: see the one that was previously logged
[task 2022-09-07T12:14:06.989Z] 12:14:06     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_newwindow_focus.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-07T12:14:06.989Z] 12:14:06     INFO - Stack trace:
[task 2022-09-07T12:14:06.989Z] 12:14:06     INFO - chrome://mochikit/content/browser-test.js:ensureVsyncDisabled:576
[task 2022-09-07T12:14:06.990Z] 12:14:06     INFO - GECKO(1668) | MEMORY STAT | vsize 1205MB | vsizeMaxContiguous 1806MB | residentFast 378MB | heapAllocated 114MB
[task 2022-09-07T12:14:06.990Z] 12:14:06     INFO - TEST-OK | browser/base/content/test/general/browser_newwindow_focus.js | took 7610ms
```