av9ash/GitBugs huggingface dataset:
Bug: No feature callout tour shown if tab sync is already set up
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-26 05:43:10+00:00
Resolved: 2022-12-13 21:24:30+00:00

The first screen of the tour looks for `#tabpickup-steps` but that doesn't exist if sync is already set up.

```
TypeError: can't access property "insertAdjacentElement", parent is null
```
Seems like there's also some issue of the automatic behavior to remove a screen without the parent to move to the next screen.
Bug: The “See what’s new” button from the “MR Gratitude” modal of the existing users’ onboarding no longer opens the “Firefox View” page
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-26 06:49:31+00:00
Resolved: 2022-09-09 13:09:02+00:00

**[Affected versions]:**
- Firefox Nightly 106.0a1 (Build ID: 20220825222149)
- Firefox Beta 105.0b3 (Build ID: 20220825185816)

**[Affected Platforms]:**
- macOS 12.5.1
- Windows 10 x64
- Ubuntu 20.04 x64

**[Prerequisites]:**
- Have the Firefox browser installed and opened.
- Have the “browser.aboutwelcome.templateMR” pref set to true.
- Have the “devtools.chrome.enabled” pref set to true.
- Have the “Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._showUpgradeDialog();” syntax copied to the clipboard.

**[Steps to reproduce]:**
1. Focus the Browser Console (Ctrl + Shift + J) and paste the syntax from prerequisites.
2. Press the “Enter” key.
3. Click the “Skip this step” button until the “MR Gratitude” modal is displayed.
4. Click the “See what’s new” button.
5. Observe what happens.

**[Expected result]:**
 - The Onboarding flow ends, and the “Firefox View” page is opened in the current tab.

**[Actual result]:**
 -  The Onboarding flow ends, and the “Firefox View” page is not opened.

**[Regression Window]:**
- The issue is not reproducible with older Nightly 105.0a1 builds. Considering this using mozregression tools, I have found the regression range. Here are the results:
 Last good revision: 5403acde30c2edaba6dac6f0890cb413e7b75c76
 First bad revision: 6e8e2b449b07a8d5a02e75692a25353ac360d852
 Pushlog: [link](https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5403acde30c2edaba6dac6f0890cb413e7b75c76&tochange=6e8e2b449b07a8d5a02e75692a25353ac360d852)

From this pushlog it seems that Bug 1783049 may have introduced this behavior.

**[Notes]:**
- This issue is not reproducible on new users’ onboarding.
- Attached is a screen recording of the issue.
Bug: [QuickActions] Question Mark is not vertically aligned in Address Bar
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-08-26 10:08:19+00:00
Resolved: 2022-10-10 09:27:00+00:00

Nightly 106.0a1 (2022-08-25) (64-Bit)
macOS 12.5.1

STR:

1.) Focus the Address Bar
2.) Hover over the question mark icon in the QuickActions section

Expected: The question mark icon should be 2px lower to be vertically aligned with the QuickActions buttons

Actual: The question mark icon is placed 2px too high.

Screenshots are attached.

Thanks.
Bug: The “Firefox View” page content is still displayed after removing the page from Toolbar
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-08-26 11:19:56+00:00
Resolved: 2022-09-14 13:21:38+00:00

**[Affected versions]:**
- Firefox Nightly 106.0a1 (Build ID: 20220825222149)

**[Affected Platforms]:**
- macOS 12.5.1
- Windows 10 x64
- Ubuntu 20.04 x64

**[Prerequisites]:**
- Have the latest version of the Firefox Nightly build installed/extracted and opened.

**[Steps to reproduce]:**
1. Right-click on the “Firefox View” tab.
2. Select the “Remove from Toolbar” option.
3. Observe what happens.

**[Expected result]:**
 - The content of the page is no longer displayed.

**[Actual result]:**
 -  The content of the page is still displayed.

**[Notes]:**
- Attached is a screen recording of the issue.
Bug: CustomizableUI doesn't build areas if the default placements contain API-provided widgets (from CustomizableWidgets or external sources), even though those widgets can't be in the DOM yet
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-08-26 11:20:25+00:00
Resolved: 2022-08-26 21:51:38+00:00

This [logic](https://searchfox.org/mozilla-central/rev/8dd35cd8f5284fbaa506aab02fe42fc87efb249e/browser/components/customizableui/CustomizableUI.jsm#963-971,979-988) governs when we rebuild area nodes when they get registered:

```js
      // For toolbars that need it, mark as dirty.
      let defaultPlacements = areaProperties.get("defaultPlacements");
      if (
        !this._builtinToolbars.has(area) ||
        placements.length != defaultPlacements.length ||
        !placements.every((id, i) => id == defaultPlacements[i])
      ) {
        gDirtyAreaCache.add(area);
      }

      // <snip>

      // We only build the toolbar if it's been marked as "dirty". Dirty means
      // one of the following things:
      // 1) Items have been added, moved or removed from this toolbar before.
      // 2) The number of children of the toolbar does not match the length of
      //    the placements array for that area.
      //
      // This notion of being "dirty" is stored in a cache which is persisted
      // in the saved state.
      if (gDirtyAreaCache.has(area)) {
        this.buildArea(area, placements, aToolbar);
```

This means that if you add a widget to the default placements for a toolbar that is not in the XUL, but provided by CustomizableWidgets.jsm or an external `createWidget` caller, it doesn't appear in the toolbar on startup.

This doesn't currently affect the navbar because it has 2 `spring` nodes in the default placements, where we update the IDs from `spring` to numerically generated unique values, so this comparison:

```
        !placements.every((id, i) => id == defaultPlacements[i])
```

fails, so we call `buildArea` anyway and the `save-to-pocket-button` does get added - even though otherwise, it would fall victim to this bug.

This burned us pretty badly with Firefox View (which we added to the tabstrip, which doesn't have any `spring` or other "special" widgets, as CUI calls them).

This is likely at least part of the reason for bug 1395983, where we've noticed we're saving placements for areas on clean new profiles, which ideally we should not need to do.
Bug: The Firefox logo is not displayed on the tab's title of the “about:firefoxview” page
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-08-26 11:25:33+00:00
Resolved: 2022-09-14 13:15:04+00:00

**[Affected versions]:**
- Firefox Nightly 106.0a1 (Build ID: 20220825222149)

**[Affected Platforms]:**
- macOS 12.5.1
- Windows 10 x64
- Ubuntu 20.04 x64

**[Prerequisites]:**
- Have the latest version of the Firefox Nightly build installed/extracted and opened.

**[Steps to reproduce]:**
1. Navigate to the “about:firefoxview” page.
2. Observe its tab title.

**[Expected result]:**
 - The tab title contains the Firefox logo.

**[Actual result]:**
 -  The tab title doesn’t contain a favicon.

**[Notes]:**
- Attached is a screenshot of the issue.
Bug: Scrolling is not working on pdfs inside presentation mode
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-08-26 13:00:34+00:00
Resolved: 2022-09-06 08:54:42+00:00

**Found in**
* Beta 105.0b3

**Affected versions**
* Release 104.0
* Beta 105.0b3
* Nightly 106.0a1

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

**Steps to reproduce**
1. Launch Firefox.
2. Navigate to http://www.pdf995.com/samples/pdf.pdf.
3. Enter into presentation mode, and start scrolling via space bar, page up/down or home/end keys from the keyboard.

**Expected result**
* The scrolling is working in every case.

**Actual result**
* The scrolling is not working at all.

**Regression range**
* This seems to be a regression as I cannot reproduce the problem on Release 103.0. I'll investigate further in order to find a regression range.
Bug: click on a history item, it automatically scrolls for a few lines, making a double click launch the wrong bookmark.
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-08-26 13:12:44+00:00
Resolved: 2022-10-03 15:00:47+00:00

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

Steps to reproduce:

1. History -> manage history -> This month  (so that the history list is a long one)
2. Crazily fast scroll the mouse wheel down, for about 10+~20+ pages  The menu will be scrolling up fast.
3. Double click on an item to launch it.






Actual results:

A different item is launched.


Expected results:

The selected (i.e. double-clicked) item should be launched.
Bug: Auto update runs despite no-auto-update policy settings
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-08-26 14:47:16+00:00
Resolved: 2023-07-27 07:45:32+00:00

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

Steps to reproduce:

Polict settings include:
"DisableAppUpdate:true",
"AppAutoUpdate:false"
"ManualAppUpdateOnly:true"


Actual results:

FF auto updates itself.


Expected results:

FF should NOT be so rude as to assume control over my emergency-backup (eye-wateringly expensive) bandwidth without my say-so. If I say "no auto update" at least heed those settings.
Bug: Investigate background color mismatch with Feature Callout in about:firefoxview
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-26 16:22:07+00:00
Resolved: 2022-09-13 00:24:03+00:00

Issues occurs with OS set to dark mode and "web appearance" set to light in `about:preferences` and "System theme - auto" as current theme. In about:firefoxview the main page background is a dark color, but the Feature Callout has a light background.
In this state the dismiss button text is white and thus not visible.
Bug: [Colorway Closet] Further tweak initial width to deal with font size changes
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2022-08-26 16:41:05+00:00
Resolved: 2022-08-27 17:45:38+00:00

Bug 1786858 made the modal's font size system-based, which is good but also means it's opened at a smaller size than before, and the degree differs across OSes. This is sort of fine in theory, as a smaller font size means we should need less space overall. But we're now way smaller than what we aimed for it seems. I'm going to propose `67em`  which should amount to just over 800px on Windows where the default font size is 12px. It's going to be a bit less than 800px on macOS and slightly above on Linux. If we still run into problems with that, we may also have to adjust breakpoint values (which are `px` based) or consider using `800px` instead of an `em` value for the initial width.
Bug: Intermittent toolkit/components/messaging-system/schemas/TriggerActionSchemas/test/browser/browser_asrouter_trigger_listeners.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-08-26 17:22:24+00:00
Resolved: 2024-04-15 12:01:57+00:00

**Filed by:** dkeeler [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=388513210&repo=try
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/f-BenEp9TaGqa0_vJymK-Q/runs/0/artifacts/public/logs/live_backing.log

---
```

```
Bug: Intermittent browser/components/firefoxview/tests/browser/browser_firefoxview_tab.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-08-26 18:17:33+00:00
Resolved: 2024-12-02 12:05:18+00:00

**Filed by:** imoraru [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=388610219&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HnoizwJ9RBWsp1t3P1VmsQ/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HnoizwJ9RBWsp1t3P1VmsQ/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2022-08-26T17:18:38.000Z] 17:18:38     INFO - TEST-PASS | browser/components/firefoxview/tests/browser/browser_firefoxview_tab.js | View count pref value is incremented when tab is selected - 
[task 2022-08-26T17:18:38.000Z] 17:18:38     INFO - Leaving test bound test_firefoxview_view_count
[task 2022-08-26T17:18:38.000Z] 17:18:38     INFO - Buffered messages finished
[task 2022-08-26T17:18:38.001Z] 17:18:38     INFO - TEST-UNEXPECTED-FAIL | browser/components/firefoxview/tests/browser/browser_firefoxview_tab.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2022-08-26T17:18:38.001Z] 17:18:38     INFO - GECKO(1495) | MEMORY STAT | vsize 16364MB | residentFast 382MB | heapAllocated 165MB
[task 2022-08-26T17:18:38.001Z] 17:18:38     INFO - TEST-OK | browser/components/firefoxview/tests/browser/browser_firefoxview_tab.js | took 46360ms
[task 2022-08-26T17:18:38.002Z] 17:18:38     INFO - checking window state
[task 2022-08-26T17:18:38.002Z] 17:18:38     INFO - GECKO(1495) | Completed ShutdownLeaks collections in process 1495
[task 2022-08-26T17:18:38.002Z] 17:18:38     INFO - TEST-START | Shutdown
[task 2022-08-26T17:18:38.003Z] 17:18:38     INFO - Browser Chrome Test Summary
[task 2022-08-26T17:18:38.003Z] 17:18:38     INFO - Passed:  177
[task 2022-08-26T17:18:38.003Z] 17:18:38     INFO - Failed:  1
[task 2022-08-26T17:18:38.003Z] 17:18:38     INFO - Todo:    0
[task 2022-08-26T17:18:38.003Z] 17:18:38     INFO - Mode:    e10s
[task 2022-08-26T17:18:38.004Z] 17:18:38     INFO - *** End BrowserChrome Test Results ***
```
Bug: nsIWindowsShellService::PinCurrentAppToTaskbarAsync breaks icon when called repeatedly
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-08-26 20:02:00+00:00
Resolved: 2023-06-13 09:29:12+00:00

If you already have Firefox pinned and call

```
Cc["@mozilla.org/browser/shell-service;1"]
  .getService(Ci.nsIWindowsShellService)
  .pinCurrentAppToTaskbarAsync(false)
```

it will change the icon of your currently pinned Firefox. The same behaviour occurs if you do not have Firefox pinned and call the function twice.

If you call it with `true` instead, the same behaviour happens for the private browsing shortcut.
Bug: In Firefox view "Recently Closed" section, in the "2 minutes ago" / "2 hours ago" etc. section, the word "ago" wraps to its own line
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-08-26 20:26:56+00:00
Resolved: 2022-08-26 22:05:36+00:00

(Not sure yet about precise STR; just filing as I'm observing an issue.)

When I view `about:firefoxview` (directly or via the toolbar/tabstrip-icon) in a Firefox window where I have closed tabs recently, the rightmost column has some awkward linewrapping that it seems like we should try to avoid.

See screenshot.  Each entry says "4 minutes ago" / "2 hours ago" / etc., with "ago" wrapped to its own line.
Bug: Clicking question mark in Quick Actions in Search bar leads to non-existent page
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-08-26 20:29:47+00:00
Resolved: 2022-08-26 20:47:05+00:00

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

Steps to reproduce:

Go to search bar
Press down arrow
Click on Question Mark option


Actual results:

https://support.mozilla.org/en-US/kb/quick-actions-firefox-search-bar?as=u&utm_source=inproduct opens which is a non-existent page


Expected results:

https://support.mozilla.org/en-US/kb/quick-actions-firefox-search-bar?as=u&utm_source=inproduct should have content
Bug: Firefox View's "Recently closed" section might be over-promising (it only shows closed tabs *from the same window* but doesn't make that clear)
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-26 20:55:08+00:00
Resolved: 2022-09-22 09:33:13+00:00

STR:
1. Using a fresh profile, open two different Firefox windows, which I'll call window "A" and "B".
2. In window A, open several new tabs, visit some sites (e.g. https://www.mozilla.org/en-US/ ) and then close at least one of those tabs.
3. Click the Firefox View button (icon at top-left of the window) in window A and in window B, and compare the contents of their "Recently Closed" sections.
4. Now, close window A entirely. Again, check Firefox View "Recently Closed" again in your remaining window (window B).

ACTUAL RESULTS:
After step 3:
* In Window A, "recently closed" shows an entry for the tab that I closed.
* In Window B, "recently closed" just says "No recently closed pages" (and then also kinda-confusingly says "Never fear losing a closed tab again. You can always retrieve it here" ... despite the fact that I just closed a page and it's not here).

After step 4, looking at my one remaining window B, it still says "No recently closed pages" and still says "Never fear losing a closed tab", despite the fact that I just closed some tabs and a window and none of that is reflected here.

EXPECTED RESULTS:
Intuitively based on the content/messaging that we're offering here, I would expect "Recently Closed" to show me the same content regardless of Firefox window (in step 3) and I would expect it to help me restore "recently closed pages" that happen to be entire windows (in step 4).


(I know we've traditionally treated undo-close-tab as a per-window thing; but this section doesn't convey that expectation at all right now.  And so it ends up feeling a bit confusing/arbitrary and hence shakes the foundation of the "Never fear" message that we're attempting to convey.)
Bug: Second Feature Callout screen is positioned too low then "jumps" to correct position on scroll or resize
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-26 21:07:37+00:00
Resolved: 2022-09-02 13:50:52+00:00

Second [Feature Callout](https://searchfox.org/mozilla-central/source/browser/components/firefoxview/featureCallout.mjs) screen is positioned too low and then "jumps" to correct position on scroll or resize. This is likely due to the fact that this screen does not have an image and for some reason the parent element being referenced in the positioning calculations is that of the previous screen.
Bug: Long URLs may wrap midway through the domain suffix (e.g. just the "m" of ".com" which looks kinda broken)
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-08-26 21:10:17+00:00
Resolved: 2022-08-26 22:05:00+00:00

STR:
1. Open a new tab and visit a URL with a long domain name like https://downforeveryoneorjustme.com

2. Close the tab (note, be sure this isn't the last tab or you won't be able to perform the next step)

3. In that same Firefox window, visit Firefox View (`about:firefoxview` or click the icon at the left of the tabstrip).  Scroll to be sure you can see the "Recently closed" section (which should show the long-domain-name site from step 1)

4. Try making the window skinnier and wider to force the domain name to *barely* need to linewrap.

ACTUAL RESULTS:
When the domain name needs to linewrap, we just wrap the last letter, "m", so it looks like:
```
downforeveryoneorjustme.co
m
```

For other sites, this can also be confusing since it may look like it's showing a particular subdomain when in fact it's not. e.g. https://phabricator.services.mozilla.com/ may wrap to 
```
phabricator.serv
ices.mozilla.com
```
...which at first glance looks like it's a reference to some nonexistent `https://ices.mozilla.com` site.

EXPECTED RESULTS:
Less-arbitrary-feeling linewrapping (sorry, I know that's vague).

If possible, we may want to try to only allow linewrapping at delimiters like `.` or ellipsize, or do some combination of the two.
Bug: Firefox View sometimes shows the wrong (previous) domain name in Recently Closed Tabs, for pages that completed navigation in the background
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-26 21:26:24+00:00
Resolved: 2022-09-22 12:39:33+00:00

STR:
1. Have a window with at least 2 tabs open (so you can close one without losing the window)
2. In one of your tabs (or in a new tab), paste https://www.example.org/ into your URL bar and hit enter.
3. In that same tab, paste https://www.mozilla.org/ into the URL bar and hit enter.
4. Click the Firefox View icon at the left end of your tab-strip.
5. Click the "x" button on the (now-backgrounded) tab that you were navigating in the earlier steps.
6. Look to see what appears in the "Recently Closed" section in Firefox View.

ACTUAL RESULTS:
An entry appears with the correct *title* taken from mozilla.org, but showing the *domain* as being example.org .  We're showing an old/stale domain that the closed tab was not actually visiting at the time that it was closed.

EXPECTED RESULTS:
The domain should show mozilla.org, not example.org
Bug: MultiStageAboutWelcome secondary CTA's arrow icon lacks context properties
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-08-26 21:57:31+00:00
Resolved: 2022-08-26 22:10:22+00:00

### STR
1. Set system theme to dark (e.g. `ui.systemUsesDarkTheme = 1`)
2. Go to about:welcome

### Expected
Arrow icon on the "Skip this step" button should be white

### Actual
It's white
Bug: Intermittent browser/components/urlbar/tests/browser/browser_paste_multi_lines.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-08-27 02:06:31+00:00
Resolved: 2022-09-20 17:04:27+00:00

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

---
```
[task 2022-08-27T01:10:48.993Z] 01:10:48     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_paste_multi_lines.js | Pasted value is correct - "http://example.com" == "http://example.com" - 
[task 2022-08-27T01:10:48.993Z] 01:10:48     INFO - Buffered messages finished
[task 2022-08-27T01:10:48.994Z] 01:10:48     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_paste_multi_lines.js | Test timed out - 
[task 2022-08-27T01:10:48.994Z] 01:10:48     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_paste_multi_lines.js | Title of autocomplete is correct - "http://example.com/" == "http://example.com/" - 
[task 2022-08-27T01:10:48.995Z] 01:10:48     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_paste_multi_lines.js | Type of autocomplete is correct - 3 == 3 - 
[task 2022-08-27T01:10:48.995Z] 01:10:48     INFO - Not taking screenshot here: see the one that was previously logged
[task 2022-08-27T01:10:48.997Z] 01:10:48     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_paste_multi_lines.js | Uncaught exception received from previously timed out test - at resource://testing-common/UrlbarTestUtils.sys.mjs:120 - TypeError: waitForFocus is not a function
[task 2022-08-27T01:10:48.997Z] 01:10:48     INFO - Stack trace:
[task 2022-08-27T01:10:48.997Z] 01:10:48     INFO - promiseAutocompleteResultPopup/<@resource://testing-common/UrlbarTestUtils.sys.mjs:120:48
[task 2022-08-27T01:10:48.997Z] 01:10:48     INFO - promiseAutocompleteResultPopup@resource://testing-common/UrlbarTestUtils.sys.mjs:120:13
[task 2022-08-27T01:10:48.997Z] 01:10:48     INFO - test_paste_after_opening_autocomplete_panel@chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_paste_multi_lines.js:152:27
[task 2022-08-27T01:10:48.997Z] 01:10:48     INFO - ensureDOMPromiseRejectionsProcessed@resource://testing-common/PromiseTestUtils.jsm:119:17
[task 2022-08-27T01:10:48.997Z] 01:10:48     INFO - nextTest@chrome://mochikit/content/browser-test.js:662:29
[task 2022-08-27T01:10:58.885Z] 01:10:58     INFO - GECKO(1396) | MEMORY STAT | vsize 1385MB | vsizeMaxContiguous 133MB | residentFast 531MB | heapAllocated 374MB
[task 2022-08-27T01:10:58.885Z] 01:10:58     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_paste_multi_lines.js | took 55025ms
[task 2022-08-27T01:10:58.902Z] 01:10:58     INFO - checking window state
[task 2022-08-27T01:10:58.903Z] 01:10:58     INFO - TEST-START | browser/components/urlbar/tests/browser/browser_paste_then_focus.js
```