av9ash/GitBugs huggingface dataset:
Bug: Context menu submenus don't close after cursor passes over
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-01-21 01:55:51+00:00
Resolved: 2022-01-22 22:56:09+00:00

## The issue

The menu selection seems to stay in the submenu, after the mouse moves off of the submenu onto another menu item.

## Steps to reproduce

1. Right click (anywhere that menu item will appear that has a submenu / dropdown)
2. Move mouse over a menu item which has a submenu (such as `Send Page to Device`, `Close Multiple Tabs`, etc.)
3. Move mouse away from submenu to another menu item (note: *without* the mouse entering the dropdown menu)

Note:  If the mouse enters the submenu then leaves, it seems to be dismissed as expected.

Also:  I have tested and this doesn't occur in other windows, so I don't believe this is anything to do with my system in particular.

## Expected results

The submenu should close as soon as the mouse leaves and goes to another menu item (even if the mouse never entered the submenu).


Note:  I am unsure if this is platform specific.  It occurs for me on linux (x86_64) but I haven't tested on another platform.
Bug: Created Containers Disappearing Upon Updating Firefox
Status: RESOLVED
Priority: --
Resolution: MOVED
Created: 2022-01-21 05:58:49+00:00
Resolved: 2022-01-27 19:01:03+00:00

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

Steps to reproduce:

Have several containers created.
Updated Firefox to the latest version
Check my created containers (done via Multi-Account Containers and via Settings)
My containers disappeared


Actual results:

All of my created containers have disappeared and the default ones have returned causing me to have to recreate all of my containers and assign the websites to them again. 


Expected results:

The containers I made should carry over no matter what. I even have Sync enabled and I still don't have the containers I made. This isn't sync related as this has happened without Sync enabled for Containers.
Bug: Ctrl+W on pinned tab react weirdly
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-01-21 08:13:31+00:00
Resolved: 2022-01-26 08:34:50+00:00

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

Steps to reproduce:

Press Ctrl+W on pinned tab.


Actual results:

The most left tab after pinned tab is hidden. I mean it seems closes but I can switch to it if I enter title in adress bar.


Expected results:

It should clause. Or maybe it should prompt to close. But is behaviour is not coherent with Ctrl+W on other tab.
Bug: Disable tab unloading in private windows (Firefox update coupled with tabs unloading can cause loss of tabs in private browsing)
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-01-21 09:17:02+00:00
Resolved: 2023-12-23 11:56:49+00:00

Since recently, tabs unload have been implemented in Firefox for not recently used tabs.
This is done in both normal windows and private browsing one.

Problem is, if Firefox is updated in the background, accidentally or not (for my par tit was through distribution's package manager, didn't noticed firefox was in the list of updates), it doesn't want to load tabs anymore (I also think this behavior is new, and that it used to be possible to use Firefox completely without restart and despite the update) because it result in what can be seen in the joined screenshot.

Problem comes when you have this behavior with private tab windows: tabs are unloaded and when it happens, address bar becomes empty resulting in the loss of tab's content.
Bug: Typed-in search query is lost after "Sorry. We just need to do one small thing to keep going."
Status: NEW
Priority: --
Created: 2022-01-21 09:23:35+00:00
Resolved: 2022-04-27 02:02:36+00:00

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

Steps to reproduce:

1. I type a search query (or paste in a link) into the search bar.
2. The "We just need to do one small thing to keep going." pops in.
3. I click the "restart" button to reopen firefox, it promises to reload all my tabs.
4. Other tabs reload, but My query is gone, forever.



Actual results:

The search query i entered last, (or the link I tried to open), is NOT restored upon restart. My progress (and/or precious time) is wasted. This occurs Every time and is driving me increasingly mad.


Expected results:

The address/link entered in the last tab should be saved&restored TOO. I mean the tab which shows "Sorry. We just need to do one small thing to keep going."
Bug: Firefox saves login windows such as log in with social services as normal which then can be restored having no content
Status: NEW
Priority: --
Created: 2022-01-21 10:40:35+00:00
Resolved: 2022-01-21 14:03:02+00:00

**Affected versions**
* Firefox 97.0a6
* Firefox 96.0.2
* Latest Nightly 98.0a1
* Nightly 74.0a1

**Affected platforms**
* Windows 10
* macOS 11
* Ubuntu 18.04

**Steps to reproduce**
1. Visit one or two websites one which is Pinterest
2. Click the log in button
3. Sign in using Google
(a new window opens where the users can log in)
4. Open Application menu (hamburger menu)
5. Click History 
6. Click Recently closed windows
7. Restore one of the windows (google sign in accounts)

**Expected result**
* Not sure what could be the expected result but maybe don't save those windows so they can be restored, just save them as history maybe.

**Actual result**
* The windows are restorable and have no content in the page. Also the Address bar in those windows are not usable.

**Regression range**
* Not sure if this is a regression or not, I was able to reproduce using an old Nightly 74.0a1 from 2020. Will search for one ASAP though.
Bug: SECOND tab do not closing . any other (1,3,4..) is ok. it started when FF96 upd
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-01-21 14:19:58+00:00
Resolved: 2022-10-12 17:08:04+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

using multiple tabs,  I try to close second tab 


Actual results:

but it can't.
any other tabs closing correctly (1,3,4..)
so, if I want close second tab I need close first and then again first.


Expected results:

just fix it. I want close my tabs in any order.
Bug: Websites detecting my Firefox x64 v96.0.2 as Chrome 96
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-01-21 15:44:07+00:00
Resolved: 2022-01-21 21:37:19+00:00

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

Steps to reproduce:

Went to multiple websites include whatsmybrowser.org


Actual results:

showed that I am using Chrome 96 when I am not


Expected results:

I would think it is detecting I am using Firefox
Bug: Unsigned DLLs used during per-user installation on Windows, prevents use of AppLocker
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-01-21 17:33:39+00:00
Resolved: 2023-03-13 20:33:51+00:00

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

Steps to reproduce:

Apply AppLocker rules allowing EXE and DLL files signed by Microsoft or Mozilla.
Run latest "Firefox Installer.exe", ignore the UAC prompt and install for the user.
If AppLocker is in block mode, the installation fails;
If AppLocker is in audit mode, the installation succeeds but Windows logs a bunch of events indicating that operations would have failed in block mode. The following unsigned DLLs are used during Firefox installation. They should be signed by Mozilla. Note that these are only part of the installer - the files that get installed are all signed. The problem is that the installer and any updates will fail when app control is in effect. It's not feasible to use hash rules to allow those DLLs because each time the files get rebuilt their hashes change.
ACCESSCONTROL.DLL
APPLICATIONID.DLL
CITYHASH.DLL
INVOKESHELLVERB.DLL
NSJSON.DLL
SHELLLINK.DLL
SYSTEM.DLL
CERTCHECK.DLL
INETBGDL.DLL
UAC.DLL
USERINFO.DLL
WEBBROWSER.DLL


Actual results:

Installation fails because the unsigned DLLs are blocked by application control.


Expected results:

Installation should succeed if the DLLs used by the installer are signed by Mozilla the way most of the Mozilla files are.
Bug: Use a lazy pref getter for the contile prefs in TopSitesFeed.jsm
Status: NEW
Priority: P3
Created: 2022-01-21 18:06:43+00:00
Resolved: 2024-04-16 17:11:20+00:00

TopSitesFeed.jsm uses a few different prefs, some of which contain JSON, and it periodically triggers lookups on those prefs and, where necessary, JSON parses.

However, these prefs don't change much, and the code could pretty easily be simplified by using `XPCOMUtils.defineLazyPreferenceGetter` to define a caching pref getter. It could also use the `aTransform` argument to do the JSON parsing (rather than doing it every time it refreshes), and use the `aOnUpdate` callback to perhaps refresh things proactively as soon as the pref changes.
Bug: Long restyle/reflow in parent process for browser.xhtml when entering/exiting fullscreen mode for web content (with lots of tabs)
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-01-21 19:47:01+00:00
Resolved: 2023-06-15 16:58:52+00:00

STR:
1. Open 1000 tabs. Here's one easy/reliable way to do this:
(a) open `about:preferences`, "Home" section
(b) for `Homepages and New Windows`, choose "Custom URLs"
(c) In the "Paste a URL..." textfield, paste in the contents of the attached text file (which is just 1000 repetitions of `about:robots|`)
(d) Open a new window. That new window will get 1000 `about:robots` tabs.

(2) Wait a bit (maybe 30-60sec, up to you) for your tabs to finish loading (just to minimize contention & background noise in the profile).

(3) In your newly-opened window with 1000 tabs, open an additional tab with some fullscreenable site, e.g. https://davidwalsh.name/demo/fullscreen.php

(4) Start profiling (Ctrl Shift 1)

(5) Click the button in the site to enter fullscreen mode.

(6) Wait a few seconds, and press Esc to exit fullscreen mode.

(7) Capture your profile (Ctrl Shift 2)


ACTUAL RESULTS:
The resulting profile shows a few fairly-long restyles/reflows in the parent process, which are associated with the fullscreen operation. The length of the restyle/reflows seems to grow with the number of tabs.

EXPECTED RESULTS:
Fullscreening web content should not cause substantial jank (and probably shouldn't cause jank that's dependent on your number of tabs).

Here's a profile of the STR (with 1000 about:robots tabs), zoomed in to the part where we enter fullscreen mode:
https://share.firefox.dev/32m7XtJ
...and when we exit fullscreen mode:
https://share.firefox.dev/3FPZqg7

In both cases (for entering and exiting), there are two long (over 100ms) restyles.  This is on my fast hardware; on slower user hardware, this is probably substantially longer. (bug  1733227 comment 8 is an example)

For comparison: if I perform the STR without having opened any/many tabs, then the restyles are pretty trivial/short.
Bug: Firefox should reflect browser.launcherProcess.enabled preference if set in user.js
Status: NEW
Priority: --
Created: 2022-01-21 21:07:29+00:00
Resolved: 2023-10-11 21:33:08+00:00

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

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

Steps to reproduce:

I edited Firefox config ("about:config"), more than one time, then searched for "browser.launcherProcess.enabled" and set it to FALSE, because I prefer less security but the ability to drag-n-drop images on desktop. Then I updated Firefox.


Actual results:

Preference "browser.launcherProcess.enabled" is reset to TRUE every time I update Firefox to a new version.


Expected results:

My explicit preference should be maintained.

---------------------------------------------------------

I don't understand why this shouldn't be fixed or, at least, an option provided to avoid having to change this every single time FF gets updated.

Stuff like "it's by design, suck it up" is what I would expect from Chrome, not Firefox. I know what I'm doing, I have been doing it for the past ten years, literally. I want Firefox to run under my VPN, while the rest of the system works outside of it. To do that I need to use FprceBindIP. To use that I need browser.launcherProcess.enabled set to False.

I always do it when I update. It's not as if you devs are somehow convincing me that I shouldn't be doing it. If I explicitly decide I want that setting to be one way, why should you force feed me a setting I have to change at every single update?

This is even more grating as it's mandatory to be able to browse under VPN while leaving the system outside the VPN. At least, that's the only way I've found so far (and I've been looking). So you're forcing me to compromise my privacy for... what, exactly? Having "safe" defaults I agree on. Forcing "safe" defaults even when a user explicitly wants to change them it's borderline offensive.

If there's a reason why the setting is reset at each and every update, please explain it.
Saying "it's by design", the way I read it, translates to "by design we choose to override clearly expressed preferences by our users because we know better, even though they have to agree on assuming responsibility when entering about:config".
Bug: Okta single sign on redirect loop
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-01-21 23:17:25+00:00
Resolved: 2022-01-26 18:51:20+00:00

Steps to reproduce:

This is for an internal page, but I suspect other Okta enabled apps might replicate it


Actual results:

As of firefox 96 I can auth from a fresh browser boot, but subsequent reauths fail with a javascript error along the lines of "Failed to copy object". Exact error not shared as it's a non-public app.

The saml?relayState=<token> changes on the token on each attempt.


Expected results:

Firefox prior to 96 and chrome properly reauth rather than sitting on the auth graphic.
Bug: context_duplicateTab opens the tab and selects it, while context_duplicateTabs opens the tab in the background
Status: ASSIGNED
Priority: --
Created: 2022-01-22 06:30:33+00:00
Resolved: 2022-02-07 17:56:41+00:00

The "Duplicate Tab" and "Duplicate Tabs" menuitems have inconsistent behavior. Here's the [plural version](https://searchfox.org/mozilla-central/rev/f7eeca4e34daea900fbedbc392c8c99f90923143/browser/base/content/tabbrowser.js#7223-7230); the singular version calls `duplicateTabIn(TabContextMenu.contextTab, 'tab')` (it could be tabshifted instead of tab). I'm not sure whether there's a pref they should be checking to determine whether the tab loads in the background or not (I don't think so?). Personally I'd prefer if they both open in the background but maybe there's a convention for this sort of thing.
Bug: Pinned tabs wont save when opening normal Firefox while InPrivate browsing is running in background
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-22 16:56:36+00:00
Resolved: 2022-08-16 13:20:53+00:00

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

Steps to reproduce:

Pin a tab
Close normal Firefox browser
Open InPrivate browsing
Open normal Firefox browser
Close normal Firefox browser
Open normal Firefox browser


Actual results:

Pinned tabs didn't save


Expected results:

Pinned tabs should have saved
Bug: Chooses wrong standard application on Kubuntu
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-22 18:36:14+00:00
Resolved: 2022-02-08 12:25:58+00:00

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

Steps to reproduce:

I chose to open a PDF in the standard application for my system. Standard action is to download.


Actual results:

No matter if I choose "download" or "open in standard application", it opens downloaded PDFs in LibreOfficeDraw, when clicking on them. I can surpass this by choosing a custom program, and it stays even when converting back to automatically download it.


Expected results:

It should take my systems standard application.
Libre Office Draw isnt even listed as an application for ".pdf" anymore, and it was below Okular always.
Bug: Moving multiple tabs between windows doesn't work
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-01-22 20:36:11+00:00
Resolved: 2022-01-26 12:12:26+00:00

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

Steps to reproduce:

1. Have two Firefox windows open, each with some number of tabs
2. In one of the windows, mark/select multiple tabs with Ctrl + Click
3. Try to move/drag them between two tabs of the other window


Actual results:

A blue line appears between the two tabs where the selected/dragged tabs are supposed to go on release. On release the line stays and the tabs are not moved.


Expected results:

Tabs should have gone to the place where the blue line appears.
Bug: Control-A binding for "select all text" ignores gtk-key-theme-name=Emacs setting which should bind it to "move to start of line"
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-01-22 23:21:25+00:00
Resolved: 2022-01-23 08:55:31+00:00

Up to version 94, Firefox for Unix honored the user setting `gtk-key-theme-name` in the `[Settings]` section of `.config/gtk-3.0/settings.ini`, so that using `gtk-key-theme-name = Emacs` would provide Emacs bindings in Gtk widgets, whether HTML text forms or the URL bar: in particular, this binds control-A to move to the start of the line.

Version 96 broke this: now typing control-A in the HTML text forms or the URL bar selects the whole text, ignoring the user-selected setting and breaking compatibility with prior versions.

Firefox should honor the user setting or, failing that, provide an alternative way to configure this.
Bug: Using unusual top level domain like "example.lo/cities" in adress bar only opens search (opposed to "example.com/cities")
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-01-23 17:45:29+00:00
Resolved: 2022-01-28 15:46:06+00:00

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

Steps to reproduce:

I'm using apache to run a local http-server, the domains I use use ".lo" as top level domain. The .lo-domains are put into the windows hosts files.

I'm now trying to write "example.lo/cities" in the address bar, the adress bar shows it will call google with this as search term.
With "example.lo/cities/" the adress bar shows it will try to call the domain.
With "example.com/cities" and "example.com/cities/" both versions try to access the domain. 


Actual results:

Calling "example.lo/cities" calls google with the search term "example.lo/cities".


Expected results:

Using "example.lo/cities" firefox should try to connect to "example.lo"! (Just like it tries with "example.com/cities".)

(Probably it has to do with my cache.)
Bug: Crash in [@ mozilla::detail::InvalidArrayIndex_CRASH | std::__pop_heap<T>]
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2022-01-23 18:14:34+00:00
Resolved: 2022-07-13 00:15:25+00:00

Maybe Fission related. (DOMFissionEnabled=1)


Crash report: https://crash-stats.mozilla.org/report/index/0c17fc8e-0fae-4e1e-aacd-c27fe0220123

Reason: ```SIGSEGV / SEGV_MAPERR```

Top 10 frames of crashing thread:
```
0 firefox-bin mozilla::detail::InvalidArrayIndex_CRASH mfbt/Assertions.cpp:50
1 libxul.so void std::__pop_heap<mozilla::ArrayIterator<mozilla::UniquePtr<TimerThread::Entry, mozilla::DefaultDelete<TimerThread::Entry> >&, nsTArray_Impl<mozilla::UniquePtr<TimerThread::Entry, mozilla::DefaultDelete<TimerThread::Entry> >, nsTArrayInfallibleAllocator> >, __gnu_cxx::__ops::_Iter_comp_iter<bool  /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/include/c++/7/bits/stl_heap.h:253
2 libxul.so NS_GetTimerDeadlineHintOnCurrentThread xpcom/threads/nsTimerImpl.cpp:140
3 libxul.so mozilla::IdlePeriodState::GetIdleDeadlineInternal xpcom/threads/IdlePeriodState.cpp:68
4 libxul.so NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:467
5 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:85
6 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306
7 libxul.so nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
8 libxul.so XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp:863
9 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306
```
Bug: Firefox Autocomplete flashing while using ibus "underlined mode" (Vietnamese IME)
Status: NEW
Priority: P3
Created: 2022-01-23 22:44:18+00:00
Resolved: 2023-01-30 16:54:39+00:00

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

Steps to reproduce:

0. Using ibus "underlined mode" to type.
1. Typing "gith" to address bar.


Actual results:

The suggest list does not appear.


Expected results:

The suggest list should appear (and likely point to "github.com" for example).
Bug: Linux test-verify Unexpected Fail - test Timed out - browser/components/places/tests/browser/browser_toolbar_drop_bookmarklet.js
Status: RESOLVED
Priority: P3
Resolution: INCOMPLETE
Created: 2022-01-24 01:49:55+00:00
Resolved: 2023-06-14 12:02:44+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15

Steps to reproduce:

1. Apply patch from bug https://bugzilla.mozilla.org/show_bug.cgi?id=1725487
2. Run `./mach try fuzzy` 
3. On open window choose: ` Linux platform` - `test-verify` , `asan` and `tsan`.
4. Test Times out.


Actual results:

https://treeherder.mozilla.org/jobs?repo=try&revision=bdf6fe2582f27370b256f19cbf547511a2786a91&selectedTaskRun=aiyATa2IRL2qft3gQprVCQ.0
Test fails on:
Linux TV-FIs && Linux Asan Opt



Expected results:

Test passes
Bug: When Searching with Bing Under 96.0.1 or 96.0.2 my Bing Search results only display one page of results, worked fine in previous versions.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-24 06:18:26+00:00
Resolved: 2022-01-26 12:15:30+00:00

Steps to reproduce:

Just open the browser and search with Bing.


Actual results:

Only one page of results shows even if it states there are 31,600,000 results and there are no next or page links at the bottom of the page.  All other browsers work as expected.


Expected results:

Show all returned search results.
Bug: Pinned tab get lost
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-24 07:49:02+00:00
Resolved: 2022-01-24 08:59:20+00:00

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

Steps to reproduce:

Open Firefox
Go to a website
Pin tab of website, eg https://web.whatsapp.com/
Open Private window (pinned tab not in Private mode)
Close main window (leave Private window open)
Reboot computer



Actual results:

The pinned tab gets lost


Expected results:

Pinned tab should stay
Bug: On Firefox version 96, file://// protocol opens files only as read only
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-01-24 12:12:00+00:00
Resolved: 2022-02-10 12:38:27+00:00

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

Steps to reproduce:

I've just installed Firefox 96 on a new computer.
I click on a link like "file://///x.x.x.x/folder/file.doc". 
I have all the permisssions to access that place,...


Actual results:

It asks me if I want to open it (with Word, in the example), or simply download it. I want to open it with Word and (without checking the checkbox that saves it as the default option) it opens the file with Word, but as a read only file, so I can't modify it.


Expected results:

The file should have been opened in read-write mode. All other computers that have previous versions of Firefox do it fine.

But, if (using Firefox 96) I do check the checkbox  then, the next time I try to open it, it does it fine.