av9ash/GitBugs huggingface dataset:
Bug: Dynamics 365 Pop-ups Do Not Work in Firefox
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-05-05 14:28:46+00:00
Resolved: 2020-11-10 16:51:58+00:00

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

Steps to reproduce:

1. go to dynamics.com - Dynamics 365 CRM suite in Office 365
2. click to open documents (PDF) that open in a new tab, which are essentially links of the form - https://crm.dynamics.com/{%43432390960016248%7D}/WebResources/new_OpenHtmlPage?Data=D43F1005-DC87-E911-A861-000D3A4F3BBF#



Actual results:

documents do not open


Expected results:

documents should open
Bug: DoH not working even after enforcing it through network.trr.mode, browser falling back to normal DNS
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-05-05 14:30:06+00:00
Resolved: 2020-05-05 15:13:05+00:00

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

Steps to reproduce:

Enabled DNS over HTTPS in preferences, then used about:config to change network.trr.mode to 3 to enforce DNS over HTTPS. Changed network.trr.bootStrap Address to 1.1.1.1


Actual results:

DNS queries are not using DoH, and they're working. (1.1.1.1/help giving this report https://1.1.1.1/help#eyJpc0NmIjoiWWVzIiwiaXNEb3QiOiJObyIsImlzRG9oIjoiTm8iLCJyZXNvbHZlcklwLTEuMS4xLjEiOiJZZXMiLCJyZXNvbHZlcklwLTEuMC4wLjEiOiJZZXMiLCJyZXNvbHZlcklwLTI2MDY6NDcwMDo0NzAwOjoxMTExIjoiTm8iLCJyZXNvbHZlcklwLTI2MDY6NDcwMDo0NzAwOjoxMDAxIjoiTm8iLCJkYXRhY2VudGVyTG9jYXRpb24iOiJERUwiLCJpc1dhcnAiOiJObyIsImlzcE5hbWUiOiJDbG91ZGZsYXJlIiwiaXNwQXNuIjoiMTMzMzUifQ==)


Expected results:

DNS queries should use DoH, or not work at all.
Bug: The language of the Open Menu is not in sync with the language setting, when updated to version 76
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-05 16:57:51+00:00
Resolved: 2020-05-11 10:34:15+00:00

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

Steps to reproduce:

1. The browser automatically updates to version 76
2. Click on Open Menu


Actual results:

The display language is Vietnamese, while the language setting is English US


Expected results:

The display language is English US as the language setting
Bug: No "Search with" entry under address bar for inputs with /
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-05 17:01:17+00:00
Resolved: 2020-05-05 19:41:51+00:00

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

Steps to reproduce:

I typed something with a / (for example a/b) in the address bar.


Actual results:

There was no "Search with" entry in the list under the address bar.


Expected results:

There should be a "Search with" entry, like for inputs without a /.
Bug: Firefox Nightly closed without me telling it to
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-05-05 17:42:15+00:00
Resolved: 2020-05-11 19:37:17+00:00

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

Steps to reproduce:

I was just doing something on Firefox Nightly.


Actual results:

It suddenly closed when I didn't tell it to close.


Expected results:

It shouldn't have closed without me asking it to do so.
Bug: Too many "s"es in the name of messaging experiment in ActionsManager.jsm
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-05-05 19:09:56+00:00
Resolved: 2024-01-22 15:44:40+00:00

The mapping of action names to actions in Normandy has too many "s"es in the work "messaging" for Messaging Experiments. It says "messsaging".

https://searchfox.org/mozilla-central/rev/7908ce29657cfd623993046bd8e38664e1c0b28e/toolkit/components/normandy/lib/ActionsManager.jsm#40
Bug: AWMesssageId has an extra S in AboutWelcomeParent.jsm
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-05-05 19:13:47+00:00
Resolved: 2020-05-21 08:17:31+00:00

See https://searchfox.org/mozilla-central/source/browser/components/newtab/aboutwelcome/AboutWelcomeParent.jsm#108
Bug: click behavior in urlbar broken
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-05 21:36:45+00:00
Resolved: 2020-05-07 13:14:46+00:00

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

Steps to reproduce:

Copying a url from the urlbar to an xterm has become much more difficult.
I click once on the url. The entire urlbar turns blue, but is not copied to the X primary selection. Further clicks make the blue color disappear, but still nothing is copied.
A double click selects a single word and copies that to the X primary selection.
(That is not something one often wants: copying part of a url.) Finally a triple click does what I needed and copies the entire url. Being an old man, triple clicking is not easy for me. The past fifty years I have not needed triple clicks, and today this is the only place in my computer usage where it is needed.


Actual results:

The results are as stated already: single click turns the url blue but does not copy, double click copies a single word, triple click copies the url.
I tried with the four possible combinations true/false of browser.urlbar.clickSelectsAll and browser.urlbar.doubleClickSelectsAll but these do not seem to have any effect.


Expected results:

It should be possible to copy the urlbar to the X primary selection using something simpler than a triple click. The preferences mentioned above should work.
(Then I would set browser.urlbar.doubleClickSelectsAll and double click in order to copy. This is what has worked for many years.)
Bug: Special characters * ^ % + # $ lose special meaning when between words
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-05-05 21:49:36+00:00
Resolved: 2020-05-07 12:30:37+00:00

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

Steps to reproduce:

Type e * a in the address bar.


Actual results:

* does not have special meaning (show only bookmarks).


Expected results:

The list under the address bar should show only bookmarks with "e" and "a", like "* e a" and "e a *" do. It is the same with the other special characters.
It still worked for example in Firefox 64.
Bug: Firefox ios bug in settings-data management page on darkmode
Status: RESOLVED
Priority: --
Resolution: MOVED
Created: 2020-05-05 22:13:57+00:00
Resolved: 2020-05-06 05:46:06+00:00

User Agent: Mozilla/5.0 (iPhone; CPU OS 13_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/25.0  Mobile/15E148 Safari/605.1.15
Firefox for Android

Steps to reproduce:

iPhone 6s; (in darkmode)
1. Open Firefox Mobile v25.0 (17803)
2. Tap menu
3. Tap settings
4. Tap Data Management


Actual results:

The name of options are invisible.


Expected results:

The name of options must be visible and readable.
Bug: Missing engine for Unitedinternet distribution (1und1 / gmx /mail.com / webde )
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-05-05 22:15:37+00:00
Resolved: 2020-07-02 00:31:53+00:00

##### Environment:
###### Windows 10
###### baseline:
         76.0RC DE build configured with 1und1 and gmx distribution
         region: de /en-us
         locale: de  / de

###### modern configuration:
         Fx 78.0a1	20200505094621
         region: de /en-us
         locale: de / de
         simulated distribution id=1und1
         simulated distribution id=gmx
         RS bucket: main-preview
       
 
##### Actual Result:
Comparison betwen 76RC legacy : 78 modern-configuration returns a 10:9 engines, in both unitedinternet distributions listed above.



##### Expected result:
Not sure if this is a valid bug, since the only difference I see betwen the two engines is the origin param, but IMO I'd expect the two engines to be present in modern-config: 
origin=moz_splugin_ff
origin=mc_splugin_ff

Ebay would be also missing from the modern-configuration for the en-us locale in the de region, but that is expected.

##### Note:
Please also confirm that the different favicon for GMX-Suche is not a issue.
Bug: Intermittent browser/components/places/tests/chrome/test_bug1163447_selectItems_through_shortcut.xhtml | uncaught exception - NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE)
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-05-05 23:40:21+00:00
Resolved: 2020-06-02 17:02:47+00:00

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

---

>[task 2020-05-05T23:06:02.438Z] 23:06:02     INFO - TEST-START | browser/components/places/tests/chrome/test_bug1163447_selectItems_through_shortcut.xhtml
[task 2020-05-05T23:06:02.664Z] 23:06:02     INFO - TEST-INFO | started process screentopng
[task 2020-05-05T23:06:03.135Z] 23:06:03     INFO - TEST-INFO | screentopng: exit 0
[task 2020-05-05T23:06:03.136Z] 23:06:03     INFO - Buffered messages logged at 23:06:02
[task 2020-05-05T23:06:03.137Z] 23:06:03     INFO - TEST-PASS | browser/components/places/tests/chrome/test_bug1163447_selectItems_through_shortcut.xhtml | The node was selected through the shortcut 
[task 2020-05-05T23:06:03.138Z] 23:06:03     INFO - Buffered messages finished
[task 2020-05-05T23:06:03.139Z] 23:06:03     INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/chrome/test_bug1163447_selectItems_through_shortcut.xhtml | uncaught exception - NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsINavHistoryContainerResultNode.hasChildren] at PTV_isContainerEmpty@chrome://browser/content/places/treeView.js:1380:12
[task 2020-05-05T23:06:03.140Z] 23:06:03     INFO - 
[task 2020-05-05T23:06:03.140Z] 23:06:03     INFO - simpletestOnerror@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:1950:18
[task 2020-05-05T23:06:03.141Z] 23:06:03     INFO - OnErrorEventHandlerNonNull*@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:1925:1
[task 2020-05-05T23:06:03.142Z] 23:06:03     INFO - GECKO(1231) | JavaScript error: chrome://browser/content/places/treeView.js, line 1380: NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsINavHistoryContainerResultNode.hasChildren]
[task 2020-05-05T23:06:03.142Z] 23:06:03     INFO - GECKO(1231) | MEMORY STAT | vsize 3036MB | residentFast 391MB | heapAllocated 160MB
[task 2020-05-05T23:06:03.142Z] 23:06:03     INFO - TEST-OK | browser/components/places/tests/chrome/test_bug1163447_selectItems_through_shortcut.xhtml | took 328ms
Bug: vh, vw should be defined according to initial containing block
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-05-05 23:46:02+00:00
Resolved: 2020-05-06 00:31:39+00:00

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

Steps to reproduce:

Viewed the attached test file  vwbug.html

Got really confused about how things are defined.

I was really trying to figure out a more complex case, but these basic operations seem incorrect to me, so I'll start here.


Actual results:

The 80% box seems to be calculated correctly. The HTML has a size, the BODY has a slightly smaller size due to margin, 80% of that looked right in the DevTools, for the top red div, and 80% of that looked right in the DevTools, for the top inner green div.

The next 4 divs are all based on vw, so the inner green div is correctly the same width as the outer red div.

The last div has both max-width and width defined. Since max-width is smaller than width, it should prevail.  However, the DevTools doesn't show a width or max-width value, the outer red div is the same width as BODY, and the inner green DIV has 0 width.


Expected results:

The viewport-percentage lengths
are relative to the size of the initial containing block. (from <https://drafts.csswg.org/css-values-3/#viewport-relative-lengths>)

Given that the initial containing block (HTML) is wider than the BODY block on which the % for the first red div is based, I expected the remaining red divs to be wider than the first red div.

In the last red div, I expected its width to be the same as the 2nd-4th red div, because max-width was set to the same as width of the others, even though width of the last was set wider.

I don't see any parse errors for the CSS in the DevTools, so I think I spelled things correctly.

I don't see a Computed width or max-width for the final green or red div in the DevTools in the Computed panel, although the actual widths are shown when hovering over those elements in the Inspector's HTML panel (but seem like they are the wrong widths).

The actual case I was trying to reproduce seemed to show that vh and vw are being calculated based on the containing block in some cases, rather than the initial containing block, and I'll keep working on a test case for that, but I had enough surprised here, that I thought I should report them now, while I continue to work on the other test case. But I decided to mention it here, so anyone testing or fixing this, might keep their eyes open for the various ways vh and vw are calculated: as far as I can see in the spec, though, they should NOT be the same as %, and they should NOT be based on any block except the initial containing block, and that block should ALWAYS be the browser viewport size, or, I suppose, the declared size of a nested browsing context... although one has to look beyond the definition of "initial containing block" to "root element" to discover that.
Bug: can't access property "heuristic", firstResult is undefined
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-05-05 23:46:11+00:00
Resolved: 2020-05-28 03:28:44+00:00

I have seen this error in console: [can't access property "heuristic", firstResult is undefined](https://searchfox.org/mozilla-central/rev/7908ce29657cfd623993046bd8e38664e1c0b28e/browser/components/urlbar/UrlbarView.jsm#513)

My browser version: 77.0a1 (2020-05-04) (64-Bit)
Bug: Reopening a tab reverts to the first history element for that tab
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-05 23:55:52+00:00
Resolved: 2020-05-11 09:35:01+00:00

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

Steps to reproduce:

Reopen a closed tab (keyboard shortcut ctrl+shift+t).


Actual results:

The reopened tab does not display the last page visited in that tab. It actually shows the first page visited from that tab when it was originally opened, and pressing the back button brings you to the last page visited. Essentially, the oldest element in the history for that tab is duplicated to be the most recent element (and current page).


Expected results:

The most recently visited page should be reopened.
Bug: animations not disabled anymore in beta 77.0b1 despite toolkit.cosmeticAnimations.enabled set to false (tab open and tab close animations)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-05-06 00:04:46+00:00
Resolved: 2020-05-14 00:49:00+00:00

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

Steps to reproduce:

Close, open or let a tab load completely


Actual results:

Animations show for each: Close, open, load (blue growing glow)


Expected results:

No animations should be shown, as it was the case before version 77.0b1. I used a 76 beta before where it was still working as expected.

Hope this bug hasn't been reported already, I did look some time for it. Thanks for your contributions to software freedom!
Bug: Intermittent browser/base/content/test/performance/browser_startup_syncIPC.js | unexpected PCompositorBridge::Msg_MakeSnapshot sync IPC before becoming idle -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-05-06 03:13:28+00:00
Resolved: 2020-09-22 17:01:34+00:00

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

---

>[task 2020-05-06T02:40:55.999Z] 02:40:55     INFO - TEST-PASS | browser/base/content/test/performance/browser_startup_syncIPC.js | sync IPC PAPZInputBridge::Msg_ReceiveMouseInputEvent allowed 1 more times before handling user events - 
[task 2020-05-06T02:40:55.999Z] 02:40:55     INFO - whitelisted sync IPC before becoming idle:
[task 2020-05-06T02:40:55.999Z] 02:40:55     INFO -   PCompositorBridge::Msg_NotifyChildCreated - at most 1 times
[task 2020-05-06T02:40:55.999Z] 02:40:55     INFO -   PAPZInputBridge::Msg_ProcessUnhandledEvent - at most 1 times
[task 2020-05-06T02:40:55.999Z] 02:40:55     INFO -   PAPZInputBridge::Msg_ReceiveMouseInputEvent - at most 1 times
[task 2020-05-06T02:40:55.999Z] 02:40:55     INFO -   PCompositorBridge::Msg_MapAndNotifyChildCreated - at most 1 times
[task 2020-05-06T02:40:56.000Z] 02:40:55     INFO -   PCompositorBridge::Msg_WillClose - at most 2 times
[task 2020-05-06T02:40:56.000Z] 02:40:56     INFO - Buffered messages finished
[task 2020-05-06T02:40:56.000Z] 02:40:56     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_startup_syncIPC.js | unexpected PCompositorBridge::Msg_MakeSnapshot sync IPC before becoming idle - 
[task 2020-05-06T02:40:56.000Z] 02:40:56     INFO - Stack trace:
[task 2020-05-06T02:40:56.000Z] 02:40:56     INFO - chrome://mochikit/content/browser-test.js:test_ok:1290
[task 2020-05-06T02:40:56.000Z] 02:40:56     INFO - chrome://mochitests/content/browser/browser/base/content/test/performance/browser_startup_syncIPC.js:null:357
[task 2020-05-06T02:40:56.000Z] 02:40:56     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1055
[task 2020-05-06T02:40:56.000Z] 02:40:56     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1095
[task 2020-05-06T02:40:56.000Z] 02:40:56     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:912
[task 2020-05-06T02:40:56.000Z] 02:40:56     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:918
[task 2020-05-06T02:40:56.000Z] 02:40:56     INFO - TEST-PASS | browser/base/content/test/performance/browser_startup_syncIPC.js | sync IPC PCompositorBridge::Msg_NotifyChildCreated happened as many times as expected before becoming idle -
Bug: 2.73 - 3.23% Images (macosx1014-64-shippable) regression on push 202234d9f7421aeeb3447909f8ba66479e6d4bf0 (Thu April 30 2020)
Status: RESOLVED
Priority: P1
Resolution: WONTFIX
Created: 2020-05-06 05:28:52+00:00
Resolved: 2023-02-09 17:37:01+00:00

Perfherder has detected a awsy performance regression from push [202234d9f7421aeeb3447909f8ba66479e6d4bf0](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=202234d9f7421aeeb3447909f8ba66479e6d4bf0). As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

   3%  Images macosx1014-64-shippable opt      6,406,851.65 -> 6,613,921.74
   3%  Images macosx1014-64-shippable opt      6,453,488.97 -> 6,629,477.37


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perf.html#/alerts?id=25840), including links to graphs and comparisons for each of the affected tests. Please follow our [guide to handling regression bugs](https://wiki.mozilla.org/TestEngineering/Performance/Handling_regression_bugs) and **let us know your plans within 3 business days, or the offending patch(es) will be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).
Bug: Huge memory leak even while sleeping
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-05-06 06:56:04+00:00
Resolved: 2020-08-12 14:14:40+00:00

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

Steps to reproduce:

Since Firefox 74, it's consuming a large about of memory and never release it on MacOS. With my usual browsing experience, before 74, I never had to restart Firefox because of its memory impact, but now I need to.
As usual, with memory based report, there are so many factor that could cause this, it's hard to reproduce, so I simplified the test to the most simple case I could do, that is: 

1. Started as safe mode without any extension
2. Loaded a bunch of tabs (my previous browsing session)
3. Saved a memory report
4. Set the computer to sleep during the night by closing lid
5. Wake up the computer
6. Saved memory report, memory increased by a lot


Actual results:

The memory increased by at least 300MB from the process manager.


Expected results:

The memory should more or less stay the same while time goes on. Please notice that I've tried to minimize the memory usage (in about:memory) but it's useless ?
Bug: Right-click menu is transparent
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-05-06 09:47:01+00:00
Resolved: 2020-05-06 10:44:36+00:00

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

Steps to reproduce:

Update to Fireofx 76


Actual results:

Whenever I right click the menu that appears has a tranparent background.
If I right click when over an input box (e.g. seach engine) or images (other items may also cause this) the menu does not appear at all, but acts as if it is there (have to click again to interact with web page again).


Expected results:

Right click menu should appear normally under all conditions
Bug: Little dot like a dead pixel near address bar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-06 09:50:17+00:00
Resolved: 2020-05-14 09:47:23+00:00

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

Steps to reproduce:

Just open your Firefox in full view (not full screen) and take a look near address bar. I use Windows 10 version 1909 build 18363.778 and Firefox 76.0 (32-bit) with 14" LCD display.


Actual results:

There is a dot near address bar, looks like a dead pixel. Look on the image I've attached.


Expected results:

The dot shouldn't appears. It is distracting enough although I know it is very minor issue. I hope it can be fixed on the next update.
Bug: [Hero Layout] The cards from hero element have wrong height if all cards are dismissed except the Hero one
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2020-05-06 12:33:47+00:00
Resolved: 2024-01-18 21:55:58+00:00

**[Affected versions]:**
- Firefox Beta 77.0a1 Build ID 20200505174119;

**[Affected Platforms]:**
- Windows 10;
- Mac OS 10.14;
- Ubuntu 18.04 x64;

**[Prerequisites]:**
- Have a Firefox Beta 77 build installed;
- Have a new profile created;
- Have the following prefs set in about:config
-- Browser.search.region to “US”
-- Browser.newtabpage.activity-stream.discoverystream.spocs-endpoint to https://spocs.getpocket.com/spocs?country=US&region=US-CA 
-- Browser.newtabpage.activity-stream.discoverystream.config to {"api_key_pref":"extensions.pocket.oAuthConsumerKey","collapsible":true,"enabled":true,"show_spocs":true,"hardcoded_layout":false,"personalized":true,"layout_endpoint":"https://getpocket.cdn.mozilla.net/v3/newtab/layout?version=1&consumer_key=$apiKey&layout_variant=hero-layout","unused_key":"unused_2"}

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Open about:newtab page.
3. Resize the browser to 1121px width.
4. Observe cards height.

**[Expected result]:**
Cards height are 468px (Hero), 222px (small cards).

**[Actual result]:**
Cards height are 624px (Hero), 300px (small cards).