av9ash/GitBugs huggingface dataset:
Bug: UX/UI inconsistency between address bar and search bar when focus
Status: RESOLVED
Priority: P5
Resolution: WONTFIX
Created: 2020-04-15 20:39:52+00:00
Resolved: 2020-11-04 22:58:42+00:00

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

Steps to reproduce:

click on address bar
then
click on search bar


Actual results:

the address bar double size to become the megabar
the search bar does not


Expected results:

both input fields should be consistent
either both of them should double size on focus, or both of them should keep their normal size.
Bug: Activating address bar search in bookmarks and history at "about:preferences#privacy" also shows visited sites on click at address bar without typing anything.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-15 20:48:30+00:00
Resolved: 2020-04-17 20:38:09+00:00

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

Steps to reproduce:

When clicking the new address bar, it shows a list of shortly visited sites, bookmarks and open tabs.

This is a privacy concern, since now at every click at the address bar, part of my history/bookmarks are shown.
This means clients I use my computer in front of at my homeoffice or colleagues (when I bring in my private laptop) might see them too.


Actual results:

When clicking the new address bar, it shows a list of shortly visited sites, bookmarks and open tabs.
One can deactivate search in history, bookmarks and open tabs "about:preferences#privacy", but then neither the list will be shown, and there will there be no search on typing.


Expected results:

Either the results should populate only at typing (as it was before), or there should be an option to disable this separately from the existing options.
Bug: nginx http basic authentication doesn't work anymore
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-04-16 06:46:04+00:00
Resolved: 2022-01-26 12:53:47+00:00

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

Steps to reproduce:

We have a local nginx web server (version 1.14.2). It could be accessed via http (without authentication) or via https with entering username and password.


Actual results:

Authentication used to work fine up until Firefox 75 version. Now there's a pop up windows "Authentication Required - Mozilla Firefox" - I enter User Name and Password, but it asks for credentials again and again and again, so nothing happens.
Everything continues to work fine with Chromium browser though.


Expected results:

User Name and Password should be accepted and access to https version of web site gained.
Bug: One click in the adressbar of a given page does highlight the address but NOT copy it into the clipboard anymore (like it used to).
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-16 06:58:51+00:00
Resolved: 2020-04-16 11:29:20+00:00

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

Steps to reproduce:

click in the adressbar


Actual results:

the adress of a given page gets highlighted


Expected results:

the adress should get highlightedbut AND get copied into the clipboard  (like it used to)
Bug: Focus addressbar when new tab is opened
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-16 07:14:18+00:00
Resolved: 2020-04-16 09:42:06+00:00

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

Steps to reproduce:

Press "+"-Button to open new tab. And type address.


Actual results:

Nothing, because addressbar had no focus.


Expected results:

Page should have opened.
Bug: operating system color scheme theme+Breeze dark theme => FF homepage not breeze dark theme
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-16 09:04:01+00:00
Resolved: 2020-04-16 16:19:35+00:00

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

Steps to reproduce:

In kde settings i select  "breeze dark" theme.
In FF settings i select "operating system color scheme" theme
then
i go to FF homepage

instead of black


Actual results:

FF homepage background is white.


Expected results:

FF homepage background is black.
Bug: When I open a new page, my bookmarks tab appear white while I am using dark mode
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-16 15:05:37+00:00
Resolved: 2020-04-16 15:07:38+00:00

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

Steps to reproduce:

Open a new page with dark theme enabled, the new page will use white theme and burn my eyes then after 3-4 seconds it will apply dark theme on the bookmarks tab


Actual results:

The page displayed white theme for 3-4 seconds then decided to apply dark theme


Expected results:

The page should not display white theme at all, this burns my eyes and even a short amount of time is enough to burn my eyes at night
Bug: Pasted emojis with skin tone does not display properly
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-04-16 16:31:56+00:00
Resolved: 2020-05-05 20:26:22+00:00

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

Steps to reproduce:

1. Copy an emoji with the non-default skin tone, or use the emoji picker (Mac) to type one in
2. Paste the emoji into a text field within a webpage (see attached gif)


Actual results:

Emoji displays as two separate emojis, as if Firefox isn't updated to the latest Unicode standard


Expected results:

Emoji should display as a single emoji with the correct skin tone
Bug: "Restart to update Firefox" button should use title case to match rest of buttons in prefs window.
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-16 18:10:52+00:00
Resolved: 2020-05-08 14:41:25+00:00

It looks particularly off since there's a button right above it that capitalizes the word "Update" ("Show Update History").

Looking at the rest of the buttons in settings, it seems that we're title casing them; guessing maybe this one just got missed since it's shown dynamically.
Bug: Window gets restored outside of view and can't be reached
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-04-16 19:18:33+00:00
Resolved: 2025-02-09 20:02:16+00:00

Here's my setup:

[-------- 1920 x 1080 -------]
[---- external monitor -----] [------ 1440 x 900 ------]
[-------- (space 1) ----------] [---laptop  (space 2) ---]
[-----------------------------] [-------------------------]

I mostly use Firefox as a single window, maximized, the external monitor (space 1).
So screenX = 0, width = 1920.

When I restart Firefox (no auto session restore), it remembers my screenX as being 1920 (which appears to be a bug in itself), and places my window "correctly" (maximized) on the space 2.
Then if I click on History -> Restore Previous Session, it brings back my window to space 1, but keeps the screenX of 1920, so the window is totally out of view and can't be reached. I can only save it by going to the browser console and changing the screenX. Restarting doesn't help.
Note that these steps can be skipped if I'm restarting for an update, which automatically triggers session restore.

In summary:
1 - Maximize Firefox on first space
2 - Quit Firefox and open it again
3 - It is placed on the second window
4 - Click to restore session
5 - Window is positioned out of view on space 1

(Steps 3 and 4 can be skipped if session is auto restored, for example by an update)
Bug: Please add the Russian version of the Yandex logo into the TippyTop images on Central.
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-16 21:17:35+00:00
Resolved: 2020-06-04 23:37:10+00:00

For Mozilla Options – General – Language – Russian. -         Could you please, switch the logo into a Russian version in accordance with our guidelines. It might be just letter “Я”, yet in Russian. (here is .svgfile:///C:/Users/tanchis/Downloads/yandex-logo-ru-RGB.svg). Please let me know, if you need more from designers.-         Can we link this logo to yandex.ru instead of linking to searchbox?
Bug: Add "abort" event handlers to remote settings's Database.jsm
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-04-16 21:25:39+00:00
Resolved: 2020-05-04 09:20:44+00:00

See bug 1624878 comment 8 . This is necessary because the `error` event may not fire and/or not make it to the transaction.
Bug: (MacOS) Firefox shouldn't rely on Sheets
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-17 01:20:36+00:00
Resolved: 2020-04-23 15:08:42+00:00

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

Steps to reproduce:

Sheets are a common way to show contextual dialogesin MacOS. Most Mac applications se them, including the Mac version of Firefox.

For example, if you remove cookies and cache from a specific site, a sheet opens, to ask you to confirm the choice.


Actual results:

Sheets animate opening. Which can trigger migraines.

As of Mojave, Sheets do not respect "prefers reduced motion" or System Preferences > Accessibility > Displays > Reduce motion.

I haven't tested Catalina.


Expected results:

But as long as Sheets animate opening, and do not respect accessibility prefs to block animation, they aren't entirely accessible. I assume the Linux and Windows versions have their own tools to display these dialogues, which may also work on the Mac.
Bug: about:logins Windows re-authentication dialog seemingly randomly asks for the username and/or password rather than biometrics
Status: NEW
Priority: P3
Created: 2020-04-17 05:47:43+00:00
Resolved: 2024-01-26 20:26:52+00:00

When I want to reveal/copy/edit a saved password (with a master password) and get the Windows dialog to re-authenticate, I seemingly randomly get three different variants of the dialog:
* Defaulting to using a PIN but with the option to use a password (ideal/expected)
* My account user pre-selected with a textbox to enter a password
* Blank username and password fields but with my username behind the More Choices options

I'm testing on Windows 10 with an account linked to my Microsoft Account.

I can't figure out the pattern to it but here are some ideas:
* The repeated failing calls to check if the password is empty are causing Windows to act like the previous authentication failed? We should maybe cache this. I think I saw that Chromium is. Edit: filed as bug 1631879.
* We aren't properly initializing the credential UI code properly so some uninitialized memory is getting used and causing the seemingly random result?

I do get the PIN option sometimes so this doesn't seem the same as bug 1624255.
Bug: Permissions can be modified even if forbidden by policy engine
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-04-17 08:27:02+00:00
Resolved: 2020-06-09 13:09:43+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Access to location is generally forbidden by GPO and locked in Settings > Permissions (like it should)
Opened maps.google.com
Via page information > Permissions (for specific site) > Access to location changed the setting to allow access on location


Actual results:

Location was given to website


Expected results:

Option should not be modifiable
Bug: Nothing is displayed on the page when logging to a Google account
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-17 09:11:12+00:00
Resolved: 2020-04-19 16:50:38+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.113 Safari/537.36

Steps to reproduce:

How to reproduce:
1. Log to a Google account


Actual results:

Nothing is displayed on the page 


Expected results:

The inbox page is opened
Bug: Cannot login to store.playstation.com
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-17 09:29:52+00:00
Resolved: 2020-04-29 22:55:34+00:00

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

Steps to reproduce:

1 - Clear all cookies and stored data for Sony/Playstation sites
2 - Open https://store.playstation.com/it-it
4 - Click on the "Accedi" (login) button


Actual results:

Nothing


Expected results:

Firefox should open a new page for user authentication.
Bug: Do not decrypt after failed HMAC verification in application-services/components/support/rc_crypto/src/aead/aes_cbc.rs#L52-L63
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-04-17 13:16:36+00:00
Resolved: 2020-08-08 16:36:35+00:00

Quoting a finding from bug 1595658 comment 2 into its own bug. I am under the impression we lost track of this and it ought to be fixed:

We have observed that the codepath in for [`open()` in aes_cbc.rs](https://github.com/mozilla/application-services/blob/270b0ea2a03c1af8e1f229b0c984b83e73cfe5df/components/support/rc_crypto/src/aead/aes_cbc.rs#L52-L63) does a CBC decryption regardless of the HMAC validation. This is purportedly to make this more constant-time (which it likely isn't) and also makes this more risky for attacks that tamper with the ciphertext and AES-CBC is generally prone to padding oracle attacks.

We should verify the HMAC  before decrypting and should not decrypt if the verification fails!

As a mitigating factor, we noted that the failure is propagated along a (relatively) long call-chain up to the main `sync()` call in sync_multiple.rs.
IncomingChangeset::fetch in changeset.rs notes specifically, that [it does not handle hmac errors but just resets the global state machine](https://github.com/mozilla/application-services/blob/25c8bfbd7c2fcdee13f268b99c6a8372f42db5fc/components/sync15/src/changeset.rs#L81).
It seems to us that the failure is handled like any other failure and the client just retries at the next sync-iteration. It's good that it does not immediately trigger attempts to retry, but we should stop decrypting when encountering an HMAC failure.
Bug: Middle click consistently opening 2 new tabs at a time.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-17 14:40:14+00:00
Resolved: 2020-04-19 18:04:44+00:00

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

Steps to reproduce:

I have found that my middle mouse button consistently opens 2 new tabs at a time.



Expected results:

It should open 1 at a time.
Bug: Incorrect remoteness on lazy tab browsers upon session restoring a non-remote tab
Status: NEW
Priority: P2
Created: 2020-04-17 15:29:56+00:00
Resolved: 2023-06-10 16:57:19+00:00

STR:

1. Start Firefox, open a new window, open two tabs, e.g. `about:preferences` and `about:config`.
3. In `about:config`, set `devtools.chrome.enabled` to true (to enable the console for later).
3. Close the window.
4. Restore the closed window: Press Alt to show the menu, > History > Restore Closed Windows > "Advanced Preferences (and 1 other tab) (Ctrl-Shift-N)"
5. Open the global JavaScript console (Ctrl-Shift-J)
6. Run the following code: `gBrowser.browsers[0].getAttribute("remote")`
7. Right-click on the first tab of the window (from step 4) > Move Tab > Move to New Window

Expected:
- At step 6, the output should be "false".
- At step 7, the tab should be moved to a new window.

Actual:
- At step 6, the output is "true", which means that the lazy browser has the incorrect remoteness.
- At step 7, a new window is opened but has a blank tab instead of the tab-to-be-moved. The tab is no longer visible in the original window, but it has not properly been removed (e.g. it still appears in `gBrowser.browsers`, and upon closing the tab there is a prompt to ask whether the window with *two* tabs should be closed). 

Extra details:
- Step 6 fails because the remoteness in `addTab` is based on `aURI`, but [that is replaced with `about:blank` for lazy browsers](https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/browser/base/content/tabbrowser.js#2573-2576), so [`remoteType` ends up being](https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/browser/base/content/tabbrowser.js#2673-2676) `"web"` (DEFAULT_REMOTE_TYPE) instead of null (NO_REMOTE).
- Step 7 fails because the tab browser [silently fails to swap when the remoteness does not match](https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/browser/base/content/tabbrowser.js#3863-3865).

PS. Step 6's stack trace is as follows (Nightly 76.0a1 buildID 20200325093457 on Linux):
```
addTab@chrome://browser/content/tabbrowser.js:2715:26
addTrustedTab@chrome://browser/content/tabbrowser.js:2523:19
addMultipleTabs@chrome://browser/content/tabbrowser.js:2951:22
ssi_restoreWindow@resource:///modules/sessionstore/SessionStore.jsm:4554:27
_restoreWindowsFeaturesAndTabs@resource:///modules/sessionstore/SessionStore.jsm:4703:12
_restoreWindowsInReversedZOrder@resource:///modules/sessionstore/SessionStore.jsm:4727:10
ssi_restoreWindows/<@resource:///modules/sessionstore/SessionStore.jsm:4787:12
promise callback*ssi_restoreWindows@resource:///modules/sessionstore/SessionStore.jsm:4781:29
ssi_undoCloseWindow/<@resource:///modules/sessionstore/SessionStore.jsm:3536:12
promise callback*ssi_undoCloseWindow@resource:///modules/sessionstore/SessionStore.jsm:3535:49
ss_undoCloseWindow@resource:///modules/sessionstore/SessionStore.jsm:355:33
undoCloseWindow@chrome://browser/content/browser.js:8173:27
oncommand@chrome://browser/content/browser.xhtml:1:1
```
Bug: webRequest overhead for data: urls from about:newtab
Status: NEW
Priority: P3
Created: 2020-04-17 15:40:19+00:00
Resolved: 2022-03-08 18:34:18+00:00

+++ This bug was initially created as a clone of Bug #1630737 +++

There's more context in bug 1630737 but if any tabs are open on about:newtab, then when a page is loaded in another tab, a thumbnail image of that page is (sometimes?) loaded in about:newtab with a data: url

Using large data: urls imposes overhead when there are extensions present with webRequest listeners (see bug 1490932 and bug 1630737 for more detail).  Since extensions are not allowed to see requests that initiate from about: pages, we could eliminate some overhead by not sending urls to the parent process in this case (the relevant code is in toolkit/components/extensions/webrequest/WebRequestContent.js).

Alternatively, perhaps about:newtab could use blob urls instead of data urls, that would avoid the specific webRequest problem and would be more efficient generally.
Bug: Top site search shortcuts show text selection cursor instead of pointer on hover
Status: NEW
Priority: P2
Created: 2020-04-17 16:17:32+00:00
Resolved: 2024-03-04 12:18:37+00:00

See attached screenshot. Note the difference in cursors when hovering over the text label for each icon.

The search tiles show a text selection cursor, while the normal top site tiles show a link pointer.

I see this on at least 75.0 and Nightly 76.0a1 (20200403063228) on macOS.
Bug: about:preferences - blurry icon
Status: NEW
Priority: P3
Created: 2020-04-17 16:51:09+00:00
Resolved: 2022-10-29 13:30:51+00:00

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

Steps to reproduce:

Open about:preferences.
Observe Sidebars 'Extensions & Themes' icon.



Actual results:

The icon is blurry.
It is blurry when compared to others
The inspector shows that its dimensions for some reason are 14x14 instead of default 16x16.



Expected results:

The icon should be sharp.
I believe it dimensions should be 16x16, just as the sibling element 'Nightly Support'
Bug: Intermittent browser/base/content/test/protectionsUI/browser_protectionsUI.js | A promise chain failed to handle a rejection: (Unable to convert rejection reason to string.) - stack: (No stack available.)
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-04-17 17:22:29+00:00
Resolved: 2020-05-12 17:07:01+00:00

**Filed by:** csabou [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer.html#?job_id=298116674&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/frCd-nXYScKPYMlvZaW-YA/runs/0/artifacts/public/logs/live_backing.log

---

[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - TEST-PASS | browser/base/content/test/protectionsUI/browser_protectionsUI.js | The blocked tracker counter is correct. - 
[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - Buffered messages finished
[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/protectionsUI/browser_protectionsUI.js | A promise chain failed to handle a rejection: (Unable to convert rejection reason to string.) - stack: (No stack available.)
[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - Rejection date: Fri Apr 17 2020 16:15:09 GMT+0000 (Greenwich Mean Time) - false == true - JS frame :: resource://testing-common/PromiseTestUtils.jsm :: assertNoUncaughtRejections :: line 265
[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - Stack trace:
[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - resource://testing-common/PromiseTestUtils.jsm:assertNoUncaughtRejections:265
[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1070
[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1074
[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:904
[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:918
[task 2020-04-17T16:15:10.661Z] 16:15:10     INFO - Not taking screenshot here: see the one that was previously logged
Bug: If you type "etc/" in the URL bar you will be forwarded to "http://www.etc.com/".
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-17 17:59:04+00:00
Resolved: 2020-04-18 10:30:19+00:00

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

Steps to reproduce:

Type "etc/", "/etc/" or for example "/etc/abcdef" in the URL bar.


Actual results:

You will be forewardet to "http://www.etc.com/"


Expected results:

The best way would have been to land on the page "https://etc/" (as with "google/")
Bug: Many Unicode characters are not displayed correctly
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-17 18:40:55+00:00
Resolved: 2020-05-07 14:26:14+00:00

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

Steps to reproduce:

I want to see several web pages with Unicode characters on them.

I've attached a simplified excerpt from the Unicode/Character reference https://en.wikibooks.org/wiki/Unicode/Character_reference/2000-2FFF


Actual results:

Firefox displays code point boxes instead.


Expected results:

See the proper characters. Like in Chrome or Internet Explorer.
Bug: Firefox update 75.0 lost MOST of my tabs (not all) using orderly update/restart of Firefox
Status: UNCONFIRMED
Priority: --
Created: 2020-04-17 19:58:21+00:00
Resolved: 2023-10-05 13:58:13+00:00

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

Steps to reproduce:

Had many windows, each with many tabs open. Could have easily been 10 windows, each with 10-20 tabs. "Restore tabs" has been set for years.

Updated Firefox from 74.x to 75.0 when prompted. (I may have downloaded the update first, and waited a day or two before restarting the browser, but shouldn't matter - it was an orderly update/restart, not a crash or reboot of the OS).


Actual results:

When I clicked "Restart Firefox", the browser closed normally.

When it started again, the correct number of WINDOWS opened, but MOST of them with just 1 blank tab! Almost all of my old tabs were gone!

Oddly, *some* (like 2 or 3) windows were restored with all their tabs - so it was clearly set to "restore tabs", and tried to.

This represents a SIGNIFICANT loss of work for me. Until I can trust Firefox to not lose my work again, I will have to rely on other browsers.


Expected results:

All windows should have opened with their previous content (tabs).