av9ash/GitBugs huggingface dataset:
Bug: [meta] Removed app-provided Search Engines reappear on update when using language packs
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-04-08 16:18:48+00:00
Resolved: 2021-05-07 14:04:01+00:00

STR

* Download 74.0.1 en-US
* Create a new profile, and create a prefs.js file with:

```
user_pref("app.update.auto", false);
user_pref("browser.search.region", "CA");
```
* Start the new profile.
* Go into Preferences -> General -> Language
* From the language drop down, select "Search for more languages"
* Select to add a different language and add "French"
* Add it to the list (it should be at the top).
* Click ok
* Apply and restart.
* Go into Preferences -> Search -> One-Click Search Engines
* Remove "Qwant" and "Wikipedia (fr)" from the list.
* Restart and confirm that they are still removed.
* Firefox -> About -> Update to 75.0.0 & restart
* Tools -> Add-ons -> Languages

See the add-on pack is out of date

* Cog symbol -> Check for updates
* Restart Firefox
* Check the search engines

Actual Results

"Qwant" and "Wikipedia (fr)" have re-appeared

Expected Results

They should have stayed hidden.
Bug: Some context data is unneededly not available during first startup runs
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-04-08 16:32:22+00:00
Resolved: 2020-04-20 22:26:47+00:00

Edit: It seems that this is not about attribution, but other expected context data.

When using the STR from bug 1626904 comment 8, the attribution data does not seem to be available to Normandy filter evaluation during first startup. These STR rely on Normandy recipe 931 being active.

> 0. [Install a version of Firefox with the target attribution data]
> 1. Cleared my local profiles.
> 2. Uninstalled any previous installation of Firefox.
> 3. Installed the try build using the target.installer.exe [note: this will not overwrite attribution data]
> 4. Did not let the install wizard to automatically open the browser.
> 5. Navigated to the path I installed Firefox in.
> 6. Used the following command to open Firefox: .\firefox.exe --first-startup --profile "C:\Users\work\AppData\Roaming\Mozilla\Firefox\Profiles\3tkdnj50.default-beta" --url about:welcome -jsconsole
> 7. Waited for Firefox to open.

It appears that the attribution data can also be placed manually, which simplifies the STR significantly.
Bug: Failure initializing search engines after polling Production Preview (Remote Settings poll preview update)
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-04-08 16:49:33+00:00
Resolved: 2023-01-02 13:15:07+00:00

##### [Environment:]
 	77.0a1 20200408033650 / Windows 10

##### [Steps:]
1. Install Nightly.
2. Install the [RS addon](https://github.com/mozilla-extensions/remote-settings-devtools)
3. Fire up the RS addon.
4. From the addon set the Environment to Prod(Preview).
5. Clear ALL local data and Clear poll data.
6. Poll server afterwhich close and reopen Nightly.

##### [Actual Result:]
No engines are initialized. 
see [debug log](https://pastebin.com/a9BZCGkv)

##### [Expected Result:]
The engines should be initialized.

##### [Note:]
1. The issue doesn't seem reproducible with Production as Environment.
2. Even though this issue might be related to the RS addon and clearing all the local and poll data, it is concerning that we can reach a state of no engines availble.
3. *Later edit* Seems my Ubuntu 18.04 machine doesn't exibit this init issue with the STR listed above. I'm gonna give it a push tomorrow with mac aswell.
Bug: Esc key doesn't work anymore to move focus away from location bar in Firefox 75
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-08 17:46:35+00:00
Resolved: 2020-04-28 04:09:26+00:00

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

Steps to reproduce:

Use ctrl-L to select the new location bar. Hit Esc to cancel. 


Actual results:

The location bar stayed focused.


Expected results:

The web page should have come back into focus. (That's what used to happen before the upgraded address bar.)
Bug: Address bar spoofing - beforeunload (Copy/Paste)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-08 18:50:00+00:00
Resolved: 2020-04-08 20:04:31+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. Open poc.html
2. Copy URL
3. Pate URL in address bar.


Actual results:

The spoof happens successfully, the URL navigates to www.gmail.com:8080 with the content displayed by attacker.
Bug: Single click in urlbar is selecting all, despite about:config settings to the contrary
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-04-08 19:54:04+00:00
Resolved: 2020-04-09 08:35:08+00:00

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

Steps to reproduce:

This is Firefox 75.0 on Windows 10.

I've set browser.urlbar.clickSelectsAll to false and browser.urlbar.doubleClickSelectsAll to true. Both are different than the default.

I single-click into the (new) address bar.


Actual results:

Up to Firefox 74, it worked. With Firefox 75, a single click in the (new) address bar always selects the text in the address bar.


Expected results:

The cursor should be in the address2 bar where I put it, with nothing selected.
Bug: Option 'Proxy DNS when using SOCKS v5' not greyed out despite GPO preventing changes
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-08 21:17:08+00:00
Resolved: 2020-04-29 01:24:25+00:00

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

Steps to reproduce:

It seems like Bug 1540584 at first sight, but it is not quite the same. 

I reproduced my findings as described below in Firefox 72.0.1 x64, 74.0.1 x64 and 76.0b2 x64 on Windows 10.
Steps:
Set 'Don't allow proxy settings to be changed.' and leave 'Proxy DNS when using SOCKS v5' unticked in the Proxy Settings of the Firefox GPO Administrative Template.
Setting this GPO results in some registry values in HKCU\Software\Policies\Mozilla\Firefox\Proxy (or HKLM), like "Locked"=dword:00000001 and "UseProxyForDNS"=dword:00000000


Actual results:

In Firefox > Options > Connection Settings, the setting 'Proxy DNS when using SOCKS v5' is unchecked (as expected), but not greyed out (not as expected). One can check this option, and then the box gets checked, but also immediately greyed out (and unchangeable). When clicking OK, and then reopening the Connection Settings, the option 'Proxy DNS when using SOCKS v5' is again unchecked and not greyed out. So this is probably a GUI glitch.


Expected results:

I expected the setting 'Proxy DNS when using SOCKS v5' in Firefox > Options > Connection Settings to be greyed out and not changeable.
Bug: Code cleanup Preference#privacy
Status: RESOLVED
Priority: P1
Resolution: INVALID
Created: 2020-04-08 21:29:56+00:00
Resolved: 2021-01-26 16:50:57+00:00

When writing a patch for https://bugzilla.mozilla.org/show_bug.cgi?id=1625228, I came across some issues in the code and tests of redundancies and typos. I'll clean them up.
Bug: Can resize certain preferences subdialogs to be narrower than expected
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-08 22:10:03+00:00
Resolved: 2020-05-18 11:34:04+00:00

STR:

1. open prefs
2. search for "manage data"
3. click button to manage data
4. drag resizer to the left/start

ER:
can't make dialog smaller so that right edge of it + close button disappears

AR:
you can.

This is a recent regression, it works fine in 76b1 . I expect I broke it in bug 1624612 but I haven't doublechecked that.
Bug: Thick Address Bar with new tabs
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-09 00:04:06+00:00
Resolved: 2020-04-09 06:25:15+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 new Tab


Actual results:

Address Bar in new Tab page is larger than usual; with some sort of padding overlapping the favourites bar a bit, Only when bar is in edit Mode


Expected results:

"normal thick" bar
Bug: Styling of "insecure password" warning doesn't look right
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-04-09 00:40:29+00:00
Resolved: 2020-05-06 09:12:00+00:00

At least compared to bug 1319919 attachment 8818946, it doesn't look quite right, although the current implementation also has a "Learn More" (and all the text gets darker (black?) when the entry is focused). Also, the whitespace around the icon doesn't look quite right either.
Bug: Cannot select text or see typing cursor in the address bar
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-04-09 01:30:52+00:00
Resolved: 2020-06-02 18:11:27+00:00

User Agent: Mozilla/5.0 (Android 5.0.1; Mobile; rv:68.0) Gecko/68.0 Firefox/68.0

Steps to reproduce:

Downloaded the latest update (version 75.0) for desktop; I assume Windows Desktop is the "trunk" version of Firefox


Actual results:

The typing cursor stopped appearing in the address bar, and I lost the ability to select text in the address bar


Expected results:

Firefox's developers should have known better than to break the address bar. I expect that kind of blunder from Microsoft and Google, but not Mozilla.
Bug: Address bar would not get focus when open New Tab
Status: NEW
Priority: P3
Created: 2020-04-09 01:57:41+00:00
Resolved: 2024-02-27 18:21:43+00:00

Steps to reproduce:
1. Open new tab if not
2. Dismiss onboarding-welcome-header if any
3. Click a fake input box in the New tab page
4. Open new tab

Actual Results:
Nothing focused

Expected Results:
Address bar should get focus
Bug: Intermittent TEST-UNEXPECTED-TIMEOUT | browser/base/content/test/touch/browser_menu_touch.js | application timed out after 370 seconds with no output
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2020-04-09 03:06:51+00:00
Resolved: 2020-04-13 06:35:02+00:00

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

---

[task 2020-04-09T01:22:55.487Z] 01:22:55     INFO - TEST-START | browser/base/content/test/touch/browser_menu_touch.js
[task 2020-04-09T01:29:05.609Z] 01:29:05     INFO - Buffered messages logged at 01:22:55
[task 2020-04-09T01:29:05.609Z] 01:29:05     INFO - Entering test bound setup
[task 2020-04-09T01:29:05.610Z] 01:29:05     INFO - Leaving test bound setup
[task 2020-04-09T01:29:05.610Z] 01:29:05     INFO - Entering test bound test_main_menu_touch
[task 2020-04-09T01:29:05.610Z] 01:29:05     INFO - TEST-PASS | browser/base/content/test/touch/browser_menu_touch.js | Menu panel (appMenu-popup) is initally closed. - 
[task 2020-04-09T01:29:05.610Z] 01:29:05     INFO - Console message: [JavaScript Warning: "XUL box for button element contained an inline #text child, forcing all its children to be wrapped in a block.  This can often be fixed by replacing “display: -moz-inline-box” with “display: -moz-inline-box; display: inline-block”." {file: "resource:///modules/PanelMultiView.jsm" line: 541}]
[task 2020-04-09T01:29:05.610Z] 01:29:05     INFO - Console message: [JavaScript Warning: "XUL box for button element contained an inline #text child, forcing all its children to be wrapped in a block.  This can often be fixed by replacing “display: -moz-inline-box” with “display: -moz-inline-box; display: inline-block”." {file: "resource:///modules/PanelMultiView.jsm" line: 541}]
[task 2020-04-09T01:29:05.610Z] 01:29:05     INFO - Buffered messages finished
[task 2020-04-09T01:29:05.610Z] 01:29:05    ERROR - TEST-UNEXPECTED-TIMEOUT | browser/base/content/test/touch/browser_menu_touch.js | application timed out after 370 seconds with no output
Bug: Address bar suggestions aren't cleared if all other suggestions are disabled
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-04-09 03:22:41+00:00
Resolved: 2020-05-04 20:07:21+00:00

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

Steps to reproduce:

1. In preferences, disable Top Sites
2. Disable Browsing history, Bookmarks, and Other tabs suggestions
3. Ctrl+L to select the address bar
4. Type something
5. Press Ctrl+L and then Delete


Actual results:

Search suggestions are still displayed, and if you press Enter the previous input is searched.


Expected results:

Search suggestions should be cleared and pressing Enter should do nothing.
Bug: Address bar covers the bookmarks bar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-04-09 05:19:33+00:00
Resolved: 2020-04-09 16:01: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 new tab, the address bar will receive focus covering the bookmarks bar (or any other) below.


Actual results:

Half of the bookmarks bar is hidden.


Expected results:

Zoom option should be configurable. The address bar should not affect the visibility of other elements.
Bug: [Megabar] --urlbar-popup-url-color and --urlbar-popup-action-color should not depend on popup colors
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-04-09 07:57:53+00:00
Resolved: 2020-04-27 08:57:52+00:00

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

Steps to reproduce:

1) Apply a custom theme that specifies a dark `popup` background color and light `popup_text` color -- e.g.:
https://addons.mozilla.org/en-US/firefox/addon/charcoal-dark-lite/

2) Focus Megabar and start typing to expand the autocomplete popup menu.


Actual results:

A) Autocomplete popup apparently takes the theme's `toolbar_field` background and `toolbar_field_text` values, rather than `popup` and `popup_text` (curiously, this does not affect the native Dark theme);

B) Worse, legibility is degraded for the autocomplete suggestion items' URL and Action text colors, which are still apparently auto-calculated from the theme's declared popup colors, rather than the actual applied colors -- cf.:
https://hacks.mozilla.org/2018/07/dark-theme-darkening-better-theming-for-firefox-quantum/

C) Theme key documentation does not specify any other way to deliberately theme those `ac-url` and `ac-action` text colors:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/theme


Expected results:

Megabar autocomplete popup menu should apply theme's declared `popup` and `popup_text` colors; however, in case that may be deemed a WONTFIX, then themes need some way to specify `ac-url` and `ac-action` text colors.
Bug: Firefox new update eats 100% of Rhyzen 3000 CPU
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-04-09 08:52:11+00:00
Resolved: 2020-06-19 17:33:10+00:00

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

Steps to reproduce:

Update firefox


Actual results:

after update CPU usage became 100%


Expected results:

should have stayed low CPU usage
Bug: Perma Windows asan tier-3 TestDllBlocklist.NoOpEntryPoint | Value of: !!hDll
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2020-04-09 09:21:34+00:00
Resolved: 2020-04-13 06:33:21+00:00

**Filed by:** archaeopteryx [at] coole-files.de
**Parsed log:** https://treeherder.mozilla.org/logviewer.html#?job_id=296845006&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PkJMu4bbQ0OOVyrE-xCNcA/runs/0/artifacts/public/logs/live_backing.log

---

Started with bug 1603974's patches.

[task 2020-04-08T21:27:59.518Z] 21:27:59     INFO -  TEST-START | TestDllBlocklist.NoOpEntryPoint
[task 2020-04-08T21:27:59.518Z] 21:27:59     INFO -  LdrLoadDll: Blocking load of 'testdllblocklist_noopentrypoint.dll' -- see http://www.mozilla.com/en-US/blocklist/
[task 2020-04-08T21:27:59.519Z] 21:27:59  WARNING -  TEST-UNEXPECTED-FAIL | TestDllBlocklist.NoOpEntryPoint | Value of: !!hDll
[task 2020-04-08T21:27:59.519Z] 21:27:59     INFO -    Actual: false
[task 2020-04-08T21:27:59.519Z] 21:27:59     INFO -  Expected: true @ z:/build/build/src/mozglue/tests/gtest/TestDLLBlocklist.cpp:82
[task 2020-04-08T21:27:59.519Z] 21:27:59  WARNING -  TEST-UNEXPECTED-FAIL | TestDllBlocklist.NoOpEntryPoint | Value of: !!::GetModuleHandleW(kLeafName.get())
[task 2020-04-08T21:27:59.519Z] 21:27:59     INFO -    Actual: false
[task 2020-04-08T21:27:59.519Z] 21:27:59     INFO -  Expected: true @ z:/build/build/src/mozglue/tests/gtest/TestDLLBlocklist.cpp:83
[task 2020-04-08T21:27:59.519Z] 21:27:59  WARNING -  TEST-UNEXPECTED-FAIL | TestDllBlocklist.NoOpEntryPoint | test completed (time: 2ms)
Bug: Firefox crashes in headless mode
Status: UNCONFIRMED
Priority: P3
Created: 2020-04-09 09:49:15+00:00
Resolved: 2021-04-26 19:57:26+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4100.3 Safari/537.36

Steps to reproduce:

View the attached example page in headless mode.

Also appears in Firefox 75, did not test in earlier versions than 74. 

Impact is primarily for automated tests failing, users should not be affected (due to headless mode). 


Actual results:

Firefox crashed.


Expected results:

Firefox should not have crashed.
Bug: The newly created vulnerable logins are not marked as vulnerable without refreshing the page after syncing logins on a new profile
Status: NEW
Priority: P3
Created: 2020-04-09 10:11:01+00:00
Resolved: 2022-10-12 00:07:50+00:00

[Affected versions]:
- Nightly 77.0a1 (Build ID: 20200408214238)
- Firefox Beta 76.0b2 (Build ID: 20200407205853)

[Affected Platforms]:
- Windows 10 x64
- Mac 10.14.6
- Ubuntu 18.04 x64

[Prerequisites]:
- Have a new Firefox profile.
- Be logged with a FxA account.
- Have at least one breached login.

[Steps to reproduce]:
1. Open the Firefox browser with the profile from prerequisites.
2. Navigate to the “about:logins” page.
3. Create at least one vulnerable login.
4. Sync the logins and close the browser.
5. Open a new Firefox profile and navigate to “about:logins”.
6. Sign in to sync.
7. Observe the vulnerable login created in step 3.

[Expected result]:
- The login is marked as vulnerable.

[Actual result]:
- The login is not marked as vulnerable.

[Notes]:
- The number increase of unmarked logins as vulnerable is directly proportional to the number of vulnerable logins created before syncing logins.
- The created login is correctly marked as vulnerable after refreshing the page.
- Attached a screen recording with the issue.
Bug: Twitter missing from GB/GB on modern configuration
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-04-09 10:42:06+00:00
Resolved: 2020-06-11 19:10:19+00:00

##### [Environment:]
 	77.0a1 20200408033650 / Windows 10

##### [Steps:]
1. Install Nightly ln-10 en_GB.
2. Create a new profile & don't start it.
3. Create an user.js in the profile directory setting region to GB: user_pref("browser.search.region", "GB");
4. Start the localized en-GB version with the profile created.
5. Observe the list of engines displayed
6. Go to about:config and set browser.search.modernConfig to false.
7. Restart browser and recheck the search engines.

##### [Actual Result:]
Twitter is missing in the modern configuration while compared with the old configuration.

##### [Expected Result:]
Twitter is available.

##### [Note:]
Search Engine devtools doesn't list twitter for the GB/GB combination, so if this is an issue, it's a configuration issue.
Bug: New tab stays bright when using Firefox Default scheme with dark system
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-04-09 10:42:13+00:00
Resolved: 2025-01-24 16:10:26+00:00

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

Steps to reproduce:

- Use Firefox Default scheme which adapts to the OS scheme
- Dark system color scheme
- Open new tab


Actual results:

Even though Firefox detects the Dark system color scheme correctly and is completely dark, the new tab page is still bright. If I manually switch to the Dark Theme, the new tab page turns dark as well.


Expected results:

New Tab page should be dark
Bug: Using emacs keybindings in Gnome, cannot close tab with Ctrl+W while address bar is in focus
Status: NEW
Priority: P3
Created: 2020-04-09 11:04:57+00:00
Resolved: 2024-10-28 15:40:29+00:00

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

Steps to reproduce:

1. Under Linux with Gnome, open the "Tweak Tool" application and change the Key Theme to "Emacs".
2. In Firefox, focus the address bar (i.e. press Ctrl+L).
3. Press Ctrl+W.


Actual results:

The selection or the last word of the text in the address bar gets deleted.


Expected results:

The current tab should have been closed.
Bug: address bar layout overflow
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-04-09 11:56:00+00:00
Resolved: 2020-04-09 12:43:10+00:00

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

Steps to reproduce:

Focus the address bar and the search bar


Actual results:

When focused, the address bar is enlarged and overflows its parents in each direction (tab bar and content). The search bar doesn't show this behaviour.

see attached gif


Expected results:

The bar is highlighted on focus, but doesn't overflow its parents.

Regression introduced in FF 75.
Bug: Cannot remove amazon.com from top sites list
Status: UNCONFIRMED
Priority: P3
Created: 2020-04-09 11:56:51+00:00
Resolved: 2023-12-27 01:48:41+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 new tab, see amazon.com in top sites list, press tree dots, press delete from history


Actual results:

Nothing, the top site remains in same place


Expected results:

The top site must dissapear.

Note: I never use amazon.com because I have my regional amazon.es and cannot understand why amazon.com is in top sites if never enter on it.
Bug: Shortcut <ctrl>+<i> doesn't show bookmark side bar
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-04-09 14:06:02+00:00
Resolved: 2020-04-09 14:13:25+00:00

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

Steps to reproduce:

In the past the Shortcut <ctrl>+<i> shows bookmark side bar.



Actual results:

Since some days (or weeks?) suddenly <ctrl>+<i> shows Page Info dialog


Expected results:

I would like to show bookmark side bar again when pressing <ctrl>+<i> 

I am using latest version 75.0 (64-Bit).

At my business pc I still have an older version (64.x I guess). There the shortcut  <ctrl>+<i> still shows bookmark side bar as I like it.

Is this intension or bug. Can I configure the assignment of a shortcut?
Bug: urlbar NOT STOP maximize
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-04-09 14:16:31+00:00
Resolved: 2020-04-09 17:47:11+00:00

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

Steps to reproduce:

I updated to latest Nightly.
URL bar - Apparently for stupid downs it grows in size (why it is not blink and squeak?) every time it gets focus!



Actual results:

Now that shit doesn't turn off! :/
Im try set false this settings:
browser.urlbar.openViewOnFocus
browser.urlbar.update1
browser.urlbar.update1.interventions
browser.urlbar.update1.searchTips
reboot browser = NO EFFECT!


Expected results:

This function that every homosexual needs very much 
MUST HAVE a way to disable it. 
Not everyone needs it.
And this is precisely the BUG!