av9ash/GitBugs huggingface dataset:
Bug: Launching Firefox with generated startup cache causes Firefox to hang forever on skeleton UI
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-19 19:13:07+00:00
Resolved: 2023-03-21 19:28:51+00:00

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

Steps to reproduce:

Upgraded to Firefox 111. The issue did not exist on previous version(s).


Actual results:

Every "second launch" of Firefox (i.e. when shut down gracefully the launch prior) causes Firefox display the skeleton UI and freeze there. It does not load ever and needs to be killed. Subsequent start works.
It also works if you delete the contents of startup cache folder, however obviously this also makes firefox take quite long to load completely.

A suggestion on Reddit told me to change a setting which resolved the issue. The setting was this:

In about:config > browser.startup.preXulSkeletonUI > change the value to false

The issue went away afterwards.


Expected results:

Firefox should just start normally...
Bug: PDF editor removes tags from tagged PDFs
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-03-19 23:01:36+00:00
Resolved: 2023-06-02 15:24:18+00:00

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

Steps to reproduce:

When I opened Firefox 111 it prompted me to try editing a PDF. I did so using a PDF that I had tagged (a PDF/UA-conformant accessible PDF).

1. Open a tagged PDF in Firefox;
2. Make any edit (text box, drawing);
3. Save PDF;
4. Open the newly-saved PDF in Adobe Acrobat.


Actual results:

All pre-existing tags are gone.


Expected results:

No tags should have been removed.

Possibly related (for background on PDF/UA if nothing else): https://bugzilla.mozilla.org/show_bug.cgi?id=861157

The attached image shows how a PDF that had been tagged has had all its tags removed after adding a drawing and text comment on the first page.
Bug: X button to close tab disappears
Status: UNCONFIRMED
Priority: --
Created: 2023-03-20 02:25:27+00:00
Resolved: 2023-09-20 20:53:31+00:00

Steps to reproduce:

1. Open a new tab
2. On a second tab, view a video fullscreen. Then close the fullscreen



Actual results:

The X button to close a tab disappears
Bug: The Location name from the Media tab under Page Info is not entirely displayed.
Status: NEW
Priority: P3
Created: 2023-03-20 10:17:57+00:00
Resolved: 2023-09-11 19:27:38+00:00

**Found in**
*  113.0a1 Nightly (20230319214532) 

**Affected versions**
*  112.0b4(20230319180129) 

**Tested platforms**
* Affected platforms: Win10, Ubuntu20.04, Mac 10.13.
* Unaffected platforms: -

**Steps to reproduce**
1. Open any page containing a long image src (e.g. https://bug647560.bmoattachments.org/attachment.cgi?id=523881)
2. Open page Info (Ctrl+I).
3. Go to Media tab and check the Location name.

**Expected result**
* Location name should be correctly displayed with an ellipsis if the name is too long.

**Actual result**
* Location name is cut off and no ellipsis is available.

**Regression range**
* Issue is logged based on comment#9 from bug 1819267.
Bug: ContentDispatchChooser handleURI should return after launchWithURI call
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-03-20 11:33:45+00:00
Resolved: 2023-03-23 13:53:01+00:00

If a site has permission and an external application is selected we skip the app chooser and permission prompts, however since we don't return after the `launchWithURI` call we still run the rest of the logic: https://searchfox.org/mozilla-central/rev/3c3ad00ab7f587e2c75e8cebb89badc4e946b10e/toolkit/mozapps/handling/ContentDispatchChooser.sys.mjs#76,109

At first I thought this could lead to duplicate `launchWithURI` calls. After some debugging it looks like the `_prompt` returns `false` for `shouldOpenHandler` which avoids this: https://searchfox.org/mozilla-central/rev/3c3ad00ab7f587e2c75e8cebb89badc4e946b10e/toolkit/mozapps/handling/ContentDispatchChooser.sys.mjs#104

Still - not returning early is confusing and could lead to bugs in the future so we should fix it.
Bug: Fields are misaligned on the Permissions  tab under Page Info.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-20 12:33:34+00:00
Resolved: 2023-03-21 12:12:15+00:00

**Found in**
*  113.0a1 Nightly (20230319214532) 

**Affected versions**
*  113.0a1 Nightly (20230319214532) 

**Tested platforms**
* Affected platforms: Win10, Ubuntu 20.04, Mac 10.13.
* Unaffected platforms: -

**Steps to reproduce**
1. Open any page containing (e.g. https://www.reddit.com/)
2. Open page Info (Ctrl+I).
3. Go to Permissions tab and check the display.

**Expected result**
* All information on Permissions tab should be correctly displayed.

**Actual result**
* Information is overlapping on Permissions tab.

**Regression range**
* Issue was discovered while verifying 1819267 and it is reproducing only on Nightly, not on Beta.
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=32be81d9b0cd316d794d6d3bdefef4b019542597&tochange=a5e9a84e1d679ca182188d8f6cc1f7310965d44e
What is mentioned on mozregression:  
DEBUG : Found commit message:
Bug 1822131 - Allow XUL elements to shrink-by-default. r=dholbert
Bug 1821920 and bug 1821871 are instances of an interesting behavior
change from bug 1820534.
The default flex-basis of old XUL was auto instead of max-content,
because of this code:
https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/layout/generic/nsFlexContainerFrame.cpp#1327
So stuff that used to wrap now no longer does, in an horizontal flex
container, since xul.css prevents XUL elements from shrinking.
Per the comment, a few tests relied on this, but I believe it should
generally be safe to shrink the items. This only causes to shrink if
they have an explicit width but no min-width (including min-width:
auto).
Some tests like test_mousescroll.xhtml hit this, because they have
explicit sizes but min-width: auto ends up being 0 effectively, but I
believe we should tweak those tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D172462
Bug: Wrong values shown in PDF viewer
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-03-20 13:49:52+00:00
Resolved: 2023-04-20 12:36:25+00:00

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

Steps to reproduce:

Unzip the attached file, that contains two valid PDF/A-3B files and a png.
Open CASO_A1.pdf in firefox using its PDF viewer. Then open CASO_B1.pdf in another tab of firefox using its PDF viewer.


Actual results:

CASO_A1.pdf shows correct data. CASO_B1.pdf shows uncorrect data (it seems to change values of bold numeric characters, eg exams results and dates), though values are right when inspecting the page (see inspect.png).
When opening CASO_B1.pdf first and CASO_A1.pdf then, CASO_B1.pdf shows correct data and CASO_A1.pdf shows uncorrect data.


Expected results:

Both CASO_A1.pdf and CASO_B1.pdf show correct data.
Bug: The "Star" Bookmarks panel no longer expands the Location section
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-20 13:57:07+00:00
Resolved: 2023-03-20 15:07:08+00:00

**Found in**
* 113.0a1 (2023-03-20)

**Affected versions**
* 113.0a1 (2023-03-20)

**Affected platforms**
* ALL

**Steps to reproduce**
1. Reach any Websites and Bookmark the page from the Star shaped button.
2. Expand the location section.

**Expected result**
* The Location section should expand.

**Actual result**
* The Location section no longer expands.

**Regression range**
15:26.57 INFO: No more integration revisions, bisection finished.
15:26.57 INFO: Last good revision: 2cc925315ab4bc13d89167646695eece8d6f6a63
15:26.57 INFO: First bad revision: b50655fcce3faf31b2c1779c263ac7c1bca94863
15:26.57 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2cc925315ab4bc13d89167646695eece8d6f6a63&tochange=b50655fcce3faf31b2c1779c263ac7c1bca94863
Bug: positioning Bug when closing several tabs in sequence
Status: NEW
Priority: --
Created: 2023-03-20 14:52:09+00:00
Resolved: 2024-03-25 14:01:35+00:00

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

Steps to reproduce:

Open several tabs until they fill the tab area and the ">" button gets activated indicating there are more tabs to the right than those visible in the tab area. Open several more tabs so there are several tabs not visible to the right (typical behaviour when you middle click several links in a page, like thumbnail images of a gallery)

Select the first of the newly opened tabs and close it clicking in the "X" button of the tab.


Actual results:

The tab closes and all tabs to the right move to the left so the "X" button of the next tab is now under the mouse pointer. This is what is expected and allows you to close several tabs quickly just by clicking the mouse button repeatedly.
But there is a moment, when there are no more tabs hidden to the right, that the position of the tabs jumps and the "X" button of the following tab doesn't fall under the pointer any more, so you are forced to reposition your pointer if you want to keep closing tabs in sequence.


Expected results:

The desirable behaviour would have been that there was no tab jump at any moment, so you can keep closing tabs by clicking the "X" button of every tab without having to move the mouse pointer up to the very last tab if needed.
Bug: Screenshots taken with click and drag scale incorrectly with windows scale factor
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2023-03-20 15:40:47+00:00
Resolved: 2024-05-09 19:52:26+00:00

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

Steps to reproduce:

1. Have windows 10 22H2 set to a different scale factor than 100%, for example 125% or 150%
2. Open screenshot tool with Ctrl + Shift + S
3. Take screenshot of region of page by dragging the mouse
4. Download screenshot with blue "download" button


Actual results:

The downloaded screenshot is incorrectly scaled:
1. The downloaded screenshot is smaller than previously seen
2. The downloaded screenshot misses information on the left and bottom part of screenshot 


Expected results:

The downloaded screenshot should contain exactly the information from the previously selected region.
Bug: Closing Firefox doesn't switch to a page that already has the "confirm close" dialog open
Status: NEW
Priority: P3
Created: 2023-03-20 16:49:35+00:00
Resolved: 2024-07-08 18:13:42+00:00

If the dialog "This page is asking you to confirm that you want to leave — information you’ve entered may not be saved." is already displayed and you navigate to another tab, clicking close, doesn't take you back to the page with the dialog open.

To recreate:

1. Open two tabs with gmail in the first tab.
2. Start composing an email in gmail.
3. Click the close button in Firefox.
4. Click over to the second tab.
5. Click close again.

It should switch to the gmail tab again.

Instead you get:

```
Uncaught Error: permitUnload is already running for this tab.
    asyncPermitUnload chrome://global/content/elements/browser-custom-element.js:1679
    permitUnload chrome://global/content/elements/browser-custom-element.js:1721
    CanCloseWindow chrome://browser/content/browser.js:8160
    WindowIsClosing chrome://browser/content/browser.js:8189
    BrowserTryToCloseWindow chrome://browser/content/browser.js:3130
    oncommand chrome://browser/content/browser.xhtml:1
    permitUnload chrome://global/content/elements/browser-custom-element.js:1735
    CanCloseWindow chrome://browser/content/browser.js:8160
    WindowIsClosing chrome://browser/content/browser.js:8189
    BrowserTryToCloseWindow chrome://browser/content/browser.js:3130
    oncommand chrome://browser/content/browser.xhtml:1
    permitUnload chrome://global/content/elements/browser-custom-element.js:1735
    _beginRemoveTab chrome://browser/content/tabbrowser.js:3872
    removeTab chrome://browser/content/tabbrowser.js:3766
    on_click chrome://browser/content/tabbrowser-tab.js:452
    handleEvent chrome://global/content/customElements.js:460
```
on the console.
Bug: Non-private windows are displaying under private taskbar icon
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-03-20 16:58:45+00:00
Resolved: 2023-08-30 13:31:28+00:00

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

Steps to reproduce:

I'm opening new Firefox window (non-private) from pinned Firefox icon.


Actual results:

Non-private windows are displayed in private window groups, together with private windows (see attached screenshot). Problem occurs also if there is no private windows opened.


Expected results:

Firefox window should be visible under "normal" icon, which I used to open it.
Bug: Listbox of Permission Setting dialog is collapsed (height=0)
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-03-20 19:34:50+00:00
Resolved: 2023-04-20 14:30:28+00:00

STR:
1. Open about:preferences#privacy
2. Click Permissions Settings button

Acrual results:
Initial height of the Listbox is 0.

Expected results:
Appropriate height.


Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c3037ba20d8b6200b240e4025a86855b74741a52&tochange=b68ba468c8215e516b1a0f00509bd70c857fd518
Bug: Button in Fonts section in about:preferences has incorrect height
Status: NEW
Priority: P3
Created: 2023-03-20 20:24:35+00:00
Resolved: 2023-03-23 20:48:54+00:00

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/113.0, build 20230320090320

The Fonts section of about:preferences, the button has incorrect height in Slovak build. When comparing to FX112 it seems like Font menubox used to shrink while it doesn't anymore.

This is reproducible even with EN build once intl.l10n.pseudo is set to accented in about:config. This may be caused by Bug 1822578 or related bugs.
Bug: about:preferences > Applications section > Content Type list visually corrupted for longer file type descriptions
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-03-20 20:52:48+00:00
Resolved: 2023-05-04 08:57:14+00:00

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/113.0, build 20230320090320

In case you have any file type with longer description in the Content Type list, the description text wraps to a second line while the list entry remains a one-liner, causing the text to overlap with each other. The screenshot shows "Microsoft Excel Comma Separated Values File" entry overlapping with "Microsoft Excel 97-2003 Worksheet (application/x-msexcel)" entry, and similarly for MS Word filetypes.

Also Save file action for one of the entries is misplaced on the screenshot.

This may be caused by Bug 1822131.
Bug: most tabcrashed/browser_aboutRestartRequired.ini tests fail in windows 11 debug with MSIX installer
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2023-03-21 02:58:34+00:00
Resolved: 2024-01-12 22:15:01+00:00

we have some test failures when running these tests on debug with a MSIX installer.  These tests are only run on debug, so this is the first time we are trying to run these on MSIX builds of Firefox.

[browser_aboutRestartRequired_buildid_false-positive.js]
 * 'System has correct platform.ini'
 * https://firefoxci.taskcluster-artifacts.net/DY689syiSMu1Ed7KOIZvhg/0/public/logs/live_backing.log

[browser_aboutRestartRequired_buildid_mismatch.js]
 * could not open file for writing
 * https://firefoxci.taskcluster-artifacts.net/LeTkzzupS96Ik8sUu8Go6g/0/public/logs/live_backing.log

[browser_aboutRestartRequired_buildid_no-platform-ini.js]
 * could not remove file
 * https://firefoxci.taskcluster-artifacts.net/LeTkzzupS96Ik8sUu8Go6g/0/public/logs/live_backing.log
Bug: Select list popup in about:preferences will change the height downward when scrolled if the list popup is extended upward.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-21 03:17:29+00:00
Resolved: 2023-03-21 10:31:15+00:00

Similar to Bug 1823552, but this is for about:preferences.

Steps To Reproduce:
1. about:preferences#general
2. Click on `Choose...` button of Language section
3. Click on `Select a language to add...`
4. Try to scroll up/down the popup
5. Optionally mouse over it

Steps To Reproduce:
1. about:preferences#general
2. Scroll to `Default Font` section so that it is lower than the center of the viewport.
3. Click on select box button of Default Font section
4. Try to scroll up/down the popup
5. Optionally mouse over it


Actual Results:
The height of the popup suddenly change.
Screencast: 
https://youtu.be/qJdZslQGUyY
https://youtu.be/Z3XQ55SYfTY

Expected Results.
Not change

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=526b311af03354ed0f06ec7572b486a51bc884f6&tochange=c15f0fb1c92375ea751b3916a4c25a34403f21b2
Bug: Menu popup  changes height/position when open/mouseover/scroll it  if the popup opened upward.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-03-21 04:08:33+00:00
Resolved: 2023-03-21 10:31:16+00:00

Similar to Bug 1823552 and Bug 1823582, but this is for menupopup.

Steps to reproduce.
1. Enable Menubar
2. Create a lot of bookmark in bookmarks menu.
3. Move/resize the browser so that the menu bar is positioned in the lower half of the screen
4. Click `Bookmarks` menu
5. Try scroll up/down  or mouse over it

Actual results:
Menu popup changes height/position.
Screencast: https://youtu.be/kRM7Hrx8X6w


Regression window:
Expected Results.
Not change

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=526b311af03354ed0f06ec7572b486a51bc884f6&tochange=c15f0fb1c92375ea751b3916a4c25a34403f21b2
Bug: Result menu dismiss option does NOT work for top picks and firefox suggest
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-03-21 08:15:02+00:00
Resolved: 2023-03-23 09:52:12+00:00

**Found in**
* Fx 112.0b4

**Affected versions**
* Fx 113.0a1
* Fx 112.0b4

**Affected platforms**
* Windows 10
* macOS
* Ubuntu 22

**Preconditions**
* browser.urlbar.resultMenu set to true
* browser.urlbar.quicksuggest.blockingEnabled set to true
* browser.urlbar.merino.endpointURL to https://merinopy.services.mozilla.com/api/v1/suggest
* browser.urlbar.merino.providers to adm,top_picks
* browser.urlbar.bestMatch.enabled to true
* browser.search.region to US
* browser.urlbar.quicksuggest.dataCollection.enabled to true
* browser.urlbar.bestMatch.blockingEnabled to true


**Steps to reproduce**
1. Launch Firefox.
2. Type 'dell' in the address bar.
3. Using the result menu, choose the dismiss option.

**Expected result**
* Top pick for dell is dismissed and not shown again.

**Actual result**
* The top pick is not dismissed.

**Regression range**
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=651dadff8b4864650922a5beaa0c458cfda0028d&tochange=11e6330ee0087beaec68da00bc61c30dbd4d16df
* Potentially regressed by: Bug 1822338 seems to be the regressor.

**Additional notes**
* Firefox suggestions dismiss does not work (sponsored or non-sponsored suggestions are not dismissed).
Bug: Focus lost if a toolbar button is removed whilst it still has focus
Status: NEW
Priority: P3
Created: 2023-03-21 13:17:26+00:00
Resolved: 2023-06-02 15:24:18+00:00

## Steps to reproduce

I think this could happen with any toolbar button that is hidden or removed whilst it has focus, but here is a specific example:

1. Open firefox.
2. Open "about:downloads".
3. For the same tab, visit "example.org".
4. Focus the anti-tracking toolbar button (F6, Shift+Tab) `#tracking-protection-icon-container`.
5. Press Alt+LeftArrow.

## Result

When returning to "about:downloads" the anti-tracking toolbar button is hidden. As such, focus is lost from the toolbar and `document.activeElement` ends up pointing to the chrome `<body>`.

## Expect

Focus should remain in the toolbar when a focused toolbar button is removed or hidden. Probably to the next toolbar button or item. In this example, it could move to the `#identity-icon-box`.

Moreover, if focus is within a toolbar button's popup and the popup and button are hidden (due to a page switch) then focus should also return to a new valid target in the toolbar.
Bug: When pasting data:text/html with CRLF codes into the address bar and opening it, the layout is different between Firefox and Chrome.
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2023-03-21 14:13:57+00:00
Resolved: 2023-04-20 09:18:20+00:00

Steps to reproduce:
1. Copy the following strings
```
data:text/html,<span>bla bla bla
bla bla</span>
```
2. Paste into address bar and press enter key

Actual results:
Firefox: `bla bla blabla bla`
Chrome : `bla bla bla bla bla`

Expected results:
both same

This does not happen if open from html file.
Bug: Intermittent TV browser/components/migration/tests/chrome/test_migration_wizard.html | single tracking bug
Status: NEW
Priority: P5
Created: 2023-03-21 14:57:47+00:00
Resolved: 2024-02-27 16:56:51+00:00

**Filed by:** nfay [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=409629443&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/F6RAZeWaQ6KluLS_xUnddA/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/F6RAZeWaQ6KluLS_xUnddA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2023-03-21T13:40:10.578Z] 13:40:10     INFO - TEST-PASS | browser/components/migration/tests/chrome/test_migration_wizard.html | Cancel button should be hidden 
[task 2023-03-21T13:40:10.579Z] 13:40:10     INFO - add_task | Leaving test_completed_progress
[task 2023-03-21T13:40:10.580Z] 13:40:10     INFO - add_task | Entering test_dialog_mode_close
[task 2023-03-21T13:40:10.580Z] 13:40:10     INFO - TEST-PASS | browser/components/migration/tests/chrome/test_migration_wizard.html | This test expects at least one enabled .cancel-close button 
[task 2023-03-21T13:40:10.581Z] 13:40:10     INFO - TEST-PASS | browser/components/migration/tests/chrome/test_migration_wizard.html | .cancel-close button should be visible in dialog mode. 
[task 2023-03-21T13:40:10.582Z] 13:40:10     INFO - Buffered messages finished
[task 2023-03-21T13:40:10.583Z] 13:40:10     INFO - TEST-UNEXPECTED-FAIL | browser/components/migration/tests/chrome/test_migration_wizard.html | Test timed out. - 
[task 2023-03-21T13:40:11.370Z] 13:40:11     INFO - GECKO(1650) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2023-03-21T13:40:11.372Z] 13:40:11     INFO - GECKO(1650) | MEMORY STAT | vsize 3209MB | residentFast 425MB | heapAllocated 176MB
[task 2023-03-21T13:40:11.376Z] 13:40:11     INFO - TEST-OK | browser/components/migration/tests/chrome/test_migration_wizard.html | took 301011ms
[task 2023-03-21T13:40:11.450Z] 13:40:11     INFO - TEST-START | Shutdown
```
Bug: Rename tabbrowser's addMultipleTabs and batchInsertingTabs to make it clear session restore is the only consumer
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-03-21 15:04:29+00:00
Resolved: 2023-03-23 21:22:22+00:00

`batchInsertingTabs` means we end up not inserting tabs into the DOM immediately, which means during `addTab` the tab may not have a `_tPos`, which can break consumers' expectations. Right now session restore is the only consumer so we'd be better off making some of the expectations around this clearer.

This is being split out from bug 1822854 to allow uplifting the fix in that bug to beta.