av9ash/GitBugs huggingface dataset:
Bug: Allow passing of utm_term through OPEN_URL and SHOW_FIREFOX_ACCOUNT actions for Spotlight
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-02-01 21:38:34+00:00
Resolved: 2023-02-21 21:30:54+00:00

Currently, there is no utm_term support for Spotlight experiments because it is not getting experiment data (experiment and branch id). As a result, experiments using `OPEN_URL` and `SHOW_FIREFOX_ACCOUNT` actions with Spotlight will not correctly use the experiment id for the utm_term.
Bug: Tabs engine has an increased amount of failing outgoing records and sync rate has dipped
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-02-02 00:18:16+00:00
Resolved: 2023-02-24 16:35:02+00:00

It seems to have started around the time rust tabs was implemented. From initial research, it looks like there are a couple of things that are happening:

1. We do not trim the tabs payload size anymore, which is most likely the largest culprit in payloads failing to upload if too large.
2. We are checking for [getClientName(id)](https://searchfox.org/mozilla-central/source/services/sync/modules/engines/tabs.js#112) in tabs.js in an async context without the `getClientName(id)` [checking if we've fetched for fxaDeviceList](https://searchfox.org/mozilla-central/source/services/sync/modules/engines/clients.js#249) which is sometimes expected to be null
 - We also don't seem to use the `device_name` in any reasonable context, which means even though we can wrap the check we should also just not call that method in the first place
3. Since quick-write is using a custom flow from the normal sync cycle, there are some small paper cut things we are doing that may not accurately reflect what the code is doing.
Bug: The “Continue to Firefox accounts” URL does not contain the experiment parameters when it is accessed from the treatment branches of the "Test Window modal vs Tab modal on about:welcome" experiment
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-02 10:23:49+00:00
Resolved: 2023-02-08 09:00:19+00:00

**[Affected versions]:**
- Firefox Beta 110.0b8 (Build ID: 20230131190033)

**[Affected Platforms]:**
- Windows 10 x64
- Windows 11 x64

**[Prerequisites]:**
- Have the latest version of Firefox Beta 110 installed and opened.
- Have the “nimbus.debug” and “devtools.chrome.enabled” prefs set to “true” in the “about:config” page.

**[Steps to reproduce]:**
1. Force enroll in the Treatment C branch of the experiment using the following link: about:studies?optin_slug=window-modal-vs-tab-modal&optin_branch=treatment-c&optin_collection=nimbus-preview
2. Focus the browser console and run the “Cc["@mozilla.org/browser/clh;1"].getService().wrappedJSObject.firstRunProfile = true; Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._maybeShowDefaultBrowserPrompt()” syntax.
3. Click the “Sign in” button from the top-right corner of the page.
4. Observe the URL’s parameters of the opened link.

**[Expected result]:**
- The URL contains a specific "utm_term" parameter for the experiment.

**[Actual result]:**
- The URL doesn’t contain a specific “utm_term” parameter for the experiment.

**[Notes]:**
- This issue is also reproducible in the Treatment A and B branches of the experiment.
- This issue is not reproducible on the Control branch of the experiment.
- Attached is a screen recording of the issue.
Bug: Can't arrow down past the QuickAction row when that row only has disabled buttons
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2023-02-02 13:48:44+00:00
Resolved: 2023-03-22 19:42:16+00:00

STR:
- Open a new tab
- Type "screen" in the address bar
- Try to arrow down past the disabled "Take a screenshot" button.

This is likely a regression from bug 1801298.
Bug: [armv6] - Firefox ESR is not running - Raspberry PI B and Raspberry Pi Zero
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-02-02 14:23:02+00:00
Resolved: 2023-02-02 15:06:19+00:00

Steps to reproduce:

I am on Raspberry Pi model B or on the Raspberry Pi Zero.
I can install Firefox ESR but I can not run it.

$ sudo apt-get install firefox-esr
Get:1 http://mirror0.it.ox.ac.uk/sites/archive.raspbian.org/archive/raspbian buster/main armhf firefox-esr armhf 91.13.0esr-1~deb10u1+rpi1 [51.4 MB]


$ firefox-esr --help
Illegal instruction

See also: https://forums.raspberrypi.com/viewtopic.php?t=263051



Expected results:

I would like to see Firefox open.
Bug: The dropdown from cam/mic permission panel has an increased width next to the selected device
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-02-02 15:02:01+00:00
Resolved: 2023-02-28 17:18:49+00:00

**Found in**
* Latest Nightly 111.0a1

**Affected versions**
* Firefox 110.0b8
* Latest Nightly 111.0a1

**Unaffected versions**
* Firefox 109.0

**Tested platforms**
* Affected platforms: Windows 10, macOS 13 (check notes area bollow) and Ubuntu 18.04.
* Unaffected platforms: none

**Preconditions**
* A device (camera or microphone) with a long name is required and connected to the PC/laptop.

**Steps to reproduce**
1. Visit a page that requires microphone and camera (eg. https://meet.jit.si/TesthingMicAndCameraForAFirefoxBug)
2. Click the device selector from mic/camera permission panel

**Expected result**
* The dropdown has the same width as the device selector.

**Actual result**
* The dropdown selector has a larger width then the device selector.

**Regression range**
* This is a two stage regression, in Stage A there the width increased by only a few pixels while in Stage B the width is very easy visible.

* **Stage A:**
* First bad: e61e04de54d1b3b90eadfedd3906fa310e887ad3
* Last good: 30fc4653fdff8501187251bf8256e50df825acbd
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=30fc4653fdff8501187251bf8256e50df825acbd&tochange=e61e04de54d1b3b90eadfedd3906fa310e887ad3
* Potentially regressed by: Bug 1805694 - Simplify menulist popup layout.

* **Stage B:**
* First bad: 5c0d75f58aaa65557a7e123efdd6573ac5845143
* Last good: b0a9b9fd9d4f509a9eb83356376a8bf96f4bba10
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b0a9b9fd9d4f509a9eb83356376a8bf96f4bba10&tochange=5c0d75f58aaa65557a7e123efdd6573ac5845143
* Potentially regressed by: Bug 1807892 - Dropdown with enough options to require a scrollbar causes options to be shortened with ellipses

**Additional notes**
* I will add bug 1807892 as the "official" regressor since after this fix this is better visible, but feel free two change it if not correct.
* Not sure how Mac is affected by this since the dropdown works and is displayed differently from Ubuntu and Windows.
Bug: Intervention cards text is flickering while typing
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-02-02 15:21:30+00:00
Resolved: 2023-02-06 12:41:43+00:00

**Note**
* Small regression affecting the intervention cards in Firefox 110 beta. 
* Not reproducible in Nightly 111 after bug 1811870 landed.

**Found in**
* Firefox 110 beta 8

**Affected versions**
* Firefox 110 beta 8

**Tested platforms**
* Affected platforms: all
* Unaffected platforms:

**Steps to reproduce**
1.  Type `clear Firefox browser` in address bar and check the intervention card

**Expected result**
* Intervention card flickers while typing

**Actual result**
* There is no flickering, intervention cards are correctly displayed

**Regression range**
* First bad: 2023-01-13
* Last good: 2023-01-12
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b7ce0bc6a79b14a75b02e7c322937625d5ba3af6&tochange=03202cdedb1ed88cdd7b6a8d4ac9e6d88300c0d4
* Potentially regressed by: 1809705

**Additional notes**
`Bug 1811870 - Enable urlbar result menu in Nightly` fixed this issue in 111, but considering urlbar result menu will be enabled by default only in 112, this might worth checking
Bug: DoH native fallback warning should not show after switching to a non-restricted network
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-02-02 15:43:17+00:00
Resolved: 2023-02-22 09:49:04+00:00

When testing the `network.trr.display_fallback_warning` option on a DoH-restricted network, I correctly see the native fallback warning. But when change networks to a non-restricted one, I'm still seeing the native fallback warning.
Bug: Filename is malformed in the "What to do with this file"... dialog when a .pdf file starts with a numeric character (or other characters that are directionless)
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-02-02 17:23:08+00:00
Resolved: 2023-03-03 09:47:32+00:00

Tested on 109.0.

Prerequisites:

Action for pdf file type is set to `Always Ask` in _Preferences > General > Files and Applications > Applications_.

(Potential) Prerequisites:

1. `pdfjs.disabled` is set to `true`.
2. `browser.download.always_ask_before_handling_new_types` is set to `true`.
3. `browser.download.useDownloadDir` is set to `false`.

STR:

Download any pdf file from e.g. arxiv.org.

Expected Behavior:

Filename in the Open with... dialog corresponds to the actual filename.

Actual Behavior:

Filename in the _Open with..._ dialog is, for example, `pdf.1234.5678` when the actual filename is `1234.5678.pdf`. https://mlnsch.files.wordpress.com/2009/08/100-moral-stories.pdf (from bug 1810132) returned `moral-stories.pdf-100`. This does not affect the subsequent _Enter name of file to save to..._ dialog. Filenames starting with an alphabetic character are not affected. I haven't tested if this also affects other file extensions.


Mozregression returned

Last good revision: 0f84b85f120f45fe6bad63d5e26b5ba4cd89f801
First bad revision: fd69d6b3aeb8e1e04334a0885f60966883a69c08
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0f84b85f120f45fe6bad63d5e26b5ba4cd89f801&tochange=fd69d6b3aeb8e1e04334a0885f60966883a69c08
Bug: Can no longer move toolbar icons to Overflow Menu
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-02 18:07:49+00:00
Resolved: 2023-02-02 18:17:21+00:00

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

Steps to reproduce:

Updated to Firefox 109.0 with existing profile

Actual results:

all my icons that used to be in the Overflow Menu had moved to the main toolbar. The Overflow Menu button was missing, and I no longer had the option to move icons back to the overflow menu. The only option shown is to pin/unpin an icon.

If I go into the Customize Toolbar settings, I can drag a built-in toolbar icon to the Overflow Menu box, but cannot drag any of my own icons to it. Once a built-in icon has been added, the Overflow Menu shows up, but there is no way to add other icons.

I tested this in a fresh/new profile, and that does not let me add 3rd-party icons to the overflow menu either.

Expected results:

Moving to a newer release of Firefox should have kept the icons already in the Overflow Menu where they had been previously (not moving them to the main toolbar)

I should be able to send icons to the Overflow Menu from the toolbar.
Bug: Make `about:certificate` clearer that the DigiNotar cert (the only cert shown there) is *not* trusted
Status: NEW
Priority: P3
Created: 2023-02-02 19:03:30+00:00
Resolved: 2023-02-17 17:00:10+00:00

STR:
1. Visit `about:certificate` (e.g. after having discovered it on `about:about`)

ACTUAL RESULTS:
There's only one entry shown in the default "Servers" view, and it's for `DigiNotar Root CA` -- I think it's there because we explicitly distrust it, but that's not-at-all-clear.  For folks who recall the DigiNotar breach, it's a bit concerning to see their certificate listed there without any additional context.

If you click the entry, we show the various metadata for the certificate, including several fields that **make it look like we consider it a valid root/signing cert**.  We show, for example:

```
Validity:
Not After   Mon, 31 Mar 2025 18:19:22 GMT

Certificate Authority   Yes

Purposes  Certificate Signing, CRL Signing
```

This^ all looks superficially like indications that we think the cert is A-OK.

EXPECTED RESULTS:
We should make it clearer that this certificate is there as result of being *untrusted*, not as a result of being trusted.
Bug: immediately after update to 109.0.1 I lost all of my bookmarks
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-02 21:14:41+00:00
Resolved: 2023-02-06 10:10:29+00:00

Steps to reproduce:

Firefox updated to 109.0.1 and I can't find any book marks. When I follow instructions to restore bookmarks from backups the system can't find any backup bookmarks files.


Actual results:

1. After the update I could find no bookmarks.
2. I followed instructions to restore bookmarks, found various backups, but when I asked the system to restore bookmarks from the backup files it could not find the files even though it said I had 42 bookmarks.


Expected results:

1. I should still have my bookmarks.
2. When I tried to restore bookmarks the system should have found the backup file.
Bug: Subscribing to a feature with ExperimentAPI.on() does not automatically trigger if there is a rollout
Status: RESOLVED
Priority: P2
Resolution: WORKSFORME
Created: 2023-02-02 22:01:29+00:00
Resolved: 2024-07-23 14:21:35+00:00

The implementation of ExperimentAPI.on() explicitly checks for the presence of an experiment, but not a rollout. As such, if you subscribe to a feature and there is only a rollout, your callback will not be called. [searchfox](https://searchfox.org/mozilla-central/rev/81fbf5597044b6811e6aa4a10f3d78e8c3080f8c/toolkit/components/nimbus/ExperimentAPI.jsm#220-235)
Bug: Pocket Saves are not Discoverable in Firefox
Status: NEW
Priority: --
Created: 2023-02-02 23:31:01+00:00
Resolved: 2023-02-17 12:07:18+00:00

There is not a clear way for the user to get to their Pocket saves from Firefox.

It is possible to get to my saves using the Pocket toolbar button, but only if 1) the current page is already in the Pocket list or 2) the user is on the new tab page.

If my Pocket list was more accessible, I would be more likely to revisit pages I have saved in Pocket and therefore get more benefit from using Pocket.

I was expecting to be able to get to my saves from the hamburger menu, Firefox account menu, or bookmarks. I think showing my saves in new tab would be useful too.
Bug: PrivateBrowsingShortcut switch on installer does not prevent creation of the shortcut
Status: NEW
Priority: P3
Created: 2023-02-03 02:01:11+00:00
Resolved: 2024-07-12 22:19:34+00:00

*I cloned the previous bug listed below as similar behavior is being witnessed with the v109.0.1 EXE or MSI installer.  The difference is an icon is created within the user's Start menu (Appdata) on first launch of Firefox post installation.  The newly created icon can be removed and isn't created on subsequent starts of Firefox.*

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

Steps to reproduce:

Tried running the regular installer from PS with the /PrivateBrowsingShortcut=false switch.


Actual results:

Firefox installed silently as expected because an argument was given, but the shortcut gets created anyway both in ProgramData during installation and in the user profile when a user runs Firefox.


Expected results:

The private browsing shortcut should not have been created.
Bug: [Address Bar] Regression: Bottom and Top 3px of Hover Highlight are not respecting a mouse click
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-02-03 08:10:22+00:00
Resolved: 2023-02-08 11:17:23+00:00

Nightly 111.0a1 (2023-02-02) (64-Bit)
macOS

Steps to reproduce:
1.) Hover over the bottom 3px of an Address Bar Hover Highlight
2.) Try a mouse click within these 3px

Actual: The mouse click is not respected.

Expected: The mouse click should be respected.

Maybe, when the hover gap was fixed in Bug 1811497, the bottom click area was not considered in the fix?

This works fine in Firefox Stable 109.0.1 (64-Bit) this works fine.

A demo of the bug is attached.

Thanks for checking.
Bug: favicon not stored in bookmarks if the page uses replaceState()
Status: NEW
Priority: P2
Created: 2023-02-03 09:30:29+00:00
Resolved: 2024-08-01 16:23:54+00:00

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

Steps to reproduce:

Visit https://sso.myfritz.net/
drag tab into bookmarks toolbar


Actual results:

bookmark appears, but with default globe favicon instead of the blue-white-red favicon that it shows in the tab


Expected results:

Should have applied favicon from tab in the bookmark entry
Bug: Intermittent browser/components/urlbar/tests/browser/browser_view_resultDisplay.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-02-03 11:47:33+00:00
Resolved: 2024-07-10 12:04:29+00:00

**Filed by:** smolnar [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=404479282&repo=mozilla-central
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Pv60pf2bSSmIP_unKrG53Q/runs/0/artifacts/public/logs/live_backing.log

---
```
INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_view_resultDisplay.js | Should have the correct number of child nodes for url - 0 == 0 - 
[task 2023-02-03T11:32:50.244Z] 11:32:50     INFO - Leaving test bound test_no_highlight_fallback_heuristic_url
[task 2023-02-03T11:32:50.245Z] 11:32:50     INFO - Buffered messages finished
[task 2023-02-03T11:32:50.245Z] 11:32:50     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_view_resultDisplay.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2023-02-03T11:32:50.246Z] 11:32:50     INFO - GECKO(4260) | MEMORY STAT | vsize 2104793MB | vsizeMaxContiguous 65151804MB | residentFast 522MB | heapAllocated 184MB
[task 2023-02-03T11:32:50.246Z] 11:32:50     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_view_resultDisplay.js | took 64414ms
[task 2023-02-03T11:32:50.246Z] 11:32:50     INFO - checking window state
```
Bug: [win] Opening a New Private window will no longer display a private browsing icon on the taskbar
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-02-03 13:30:44+00:00
Resolved: 2023-02-06 14:59:46+00:00

**Found in**
* 111.0a1 (20230203091639)

**Affected versions**
* 111.0a1 (20230203091639)



**Tested platforms**
* Affected platforms: Windows 11x64, Windows 10x64
* Unaffected platforms: macOS, Ubuntu



**Steps to reproduce**
1. Open Firefox and open a New private window.
2. Observe the taskbar.


**Expected result**
* The newly opened private window appears on the taskbar.

**Actual result**
* The newly opened private window is not displayed on the taskbar.

**Regression range**
* Last good revision: 06679a025cf7d086f64e329727d770dd6181a41d
First bad revision: 3ef47a8cdcfdae694bd8cfd0de140009ba7ad21e
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=06679a025cf7d086f64e329727d770dd6181a41d&tochange=3ef47a8cdcfdae694bd8cfd0de140009ba7ad21e
Unfortunately, I don’t know which of the bugs is the regressor for sure. Adding both patch authors to the cc list.


**Additional notes**
* Attached a screen recording.
Bug: Restore previous Session Even Though Option Is Off
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-02-03 13:45:08+00:00
Resolved: 2024-01-22 12:36:13+00:00

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

Steps to reproduce:

When I open Firefox it attempts to restore previous session even though new windows and tabs settings are blank page.  This is a new bug that was not in earlier releases.


Actual results:

Firefox connected to previous URL and the previous web page was displayed.


Expected results:

Firefox not be connected to a URL and a blank page displayed
Bug: Screenshots fails if the overlay selected region is too big
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-02-03 16:37:22+00:00
Resolved: 2023-04-11 21:08:39+00:00

`cropScreenshotRectIfNeeded` should be called from `createCanvas` so we crop all screenshots not just save full page or visible page.

We should also consider limiting the selected region to the max dimension and prevent the selected region from being to big in the page
Bug: Right-click context menu appears behind Bookmarks bar drop down making it difficult top copy URLs
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-03 17:27:39+00:00
Resolved: 2023-02-03 18:17:23+00:00

NOTE: Filing for a third party, I wasn't able to reproduce this on Nightly/macOS 13.

> You'll notice that when you right click on bookmarks the popup hides behind so it's impossible to copy a url from your bookmarks.
Bug: Recently closed tabs filters about:newtab but doesn't when using extensions for new tab
Status: NEW
Priority: P3
Created: 2023-02-03 18:35:35+00:00
Resolved: 2024-01-05 16:55:29+00:00

If you're using the default new tab experience, opening and closing a newtab doesn't show up in recently closed.

## STR:

* Install a new tab extension like [Tabby Cat](https://addons.mozilla.org/en-US/firefox/addon/tabby-cat-friend/).
* Open a new tab and close it
* The new tab page "index.html" shows up in Recently closed (see screenshot).

## What should happen:

* New tabs pages from an extension would ideally be filtered out.

See screenshot for details
Bug: Duplicate UTM Terms in Send Download link on MOBILE_DOWNLOAD screen
Status: RESOLVED
Priority: P1
Resolution: WONTFIX
Created: 2023-02-03 20:31:34+00:00
Resolved: 2023-04-10 21:28:12+00:00

'Send yourself download link on' MOBILE_DOWNLOAD screen points to
https://www.mozilla.org/en-US/firefox/mobile/get-app/?utm_medium=firefox-desktop&utm_source=onboarding-modal&utm_campaign=mr2022&utm_content=new-global&utm_source=activity-stream&utm_campaign=firstrun&utm_medium=referral&utm_term=aboutwelcome-default-screen

URL has utm params duplicated because of utm params in the url in JSON and addUtmParams method invoked for OPEN_URL

https://searchfox.org/mozilla-central/rev/a7156afbfa575f12f60b1c8bf099d547c29bcadf/browser/components/newtab/aboutwelcome/lib/AboutWelcomeDefaults.jsm#250

https://searchfox.org/mozilla-central/rev/a7156afbfa575f12f60b1c8bf099d547c29bcadf/browser/components/newtab/content-src/aboutwelcome/components/MultiStageAboutWelcome.jsx#328

https://searchfox.org/mozilla-central/rev/a7156afbfa575f12f60b1c8bf099d547c29bcadf/browser/components/newtab/content-src/asrouter/templates/FirstRun/addUtmParams.js#20


STR
1. Open about:welcome
2. Signout of FxA, If logged into FxA account
3. Navigate to Mobile Download screen
4. Click on Send yourself download link
Bug: Feature Callout dark mode colors don't look quite right
Status: RESOLVED
Priority: P2
Resolution: WORKSFORME
Created: 2023-02-03 21:51:45+00:00
Resolved: 2024-04-25 18:07:15+00:00

[Figma prototype](https://www.figma.com/file/mrjF8OroTxjSZglHUjRybQ/Product-tour?node-id=474%3A36363&t=jQk0weTif1NXkpz0-4)

The border, for example, is the same in dark mode as in light mode (nearly white). So the contrast is much, much more intense in dark mode. Also, the background color in the prototype is #42414D which is lighter than the background of Firefox View. But on tree, the background of the callout is darker than Firefox View. So the buttons on the callout end up being lighter than the callout background, when in the prototype they are darker than the callout background.
Bug: Feature Callouts without steps have too much padding at the bottom
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-02-03 22:06:21+00:00
Resolved: 2023-02-07 16:46:12+00:00

The steps element has negative block margins, so it's sort of artificially pulling the bottom edge of the callout up. So removing it eliminates that effect, causing there to be excessive space between the bottom button and the bottom edge of the callout. Not sure what the cleanest way to fix this is. Add a negative spacer in place of the steps indicator? Just leave the steps indicator in the DOM but give it `visibility: hidden`? Get rid of the negative margins for the steps indicator altogether, and instead just bring the margins of other elements into line with the prototype?