av9ash/GitBugs huggingface dataset:
Bug: Bookmark keyword search and search mode search uses the default engine search when there is restrict symbol at the end of search string
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-01-09 23:23:02+00:00
Resolved: 2024-01-17 13:03:24+00:00

While working on [Bug 1667639 - Ending a keyword query with a question mark (?) searches default search engine instead and restricts to search](https://bugzilla.mozilla.org/show_bug.cgi?id=1667639) Marco and I found another bug. This bug can manifest in two ways: 
 
### 1 Bookmark keyword search

**Steps To Reproduce:**
1. Add a bookmark keyword
    a. Go to https://unsplash.com/
    b. Right click on the page's search bar
    c. Click on "Add a keyword for this search" 
    d. Add "unsplash" as the keyword and save it. 

2. Type `unsplash kitten *` onto Firefox's address bar
3. Hit enter and it will search `unsplash kitten *` on the default search engine. 

**Expected:**
It should search `kitten *` on the unsplash website. 

**Actual:**
It searched `unsplash kitten *` on the default engine search result page. 

### 2 Alias Search

1. Navigate to `about:preferences#search`
2. Add a keyword for one the search engines. E.g. `wiki` for wikpedia
3. Copy `wiki kitten?` or `wiki kitten ?` (either one would work)
4. Right click the address bar by clicking `Paste and Go` 
5. It searched `wiki kitten?` on the default search engine

**Expected:**
It should search `kitten?` on wikipedia. 

**Actual:**
It searched `kitten?` on the default engine search result page.
Bug: Intermittent browser/components/screenshots/tests/browser/browser_screenshots_drag_test.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-01-10 04:17:11+00:00
Resolved: 2025-02-10 12:06:56+00:00

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

---
```
[task 2024-01-10T02:34:07.961Z] 02:34:07     INFO - TEST-PASS | browser/components/screenshots/tests/browser/browser_screenshots_drag_test.js | The copied image from the overlay is 300px in height - 300 == 300 - 
[task 2024-01-10T02:34:07.962Z] 02:34:07     INFO - Leaving test bound resizeAllCorners
[task 2024-01-10T02:34:07.962Z] 02:34:07     INFO - Entering test bound test_otherMouseButtons
[task 2024-01-10T02:34:07.963Z] 02:34:07     INFO - Buffered messages finished
[task 2024-01-10T02:34:07.963Z] 02:34:07     INFO - TEST-UNEXPECTED-FAIL | browser/components/screenshots/tests/browser/browser_screenshots_drag_test.js | Test timed out - 
[task 2024-01-10T02:34:07.963Z] 02:34:07     INFO - GECKO(3516) | Completed ShutdownLeaks collections in process 1928
[task 2024-01-10T02:34:07.964Z] 02:34:07     INFO - TEST-START | Shutdown
[task 2024-01-10T02:34:07.964Z] 02:34:07     INFO - Browser Chrome Test Summary
[task 2024-01-10T02:34:07.964Z] 02:34:07     INFO - Passed:  438
[task 2024-01-10T02:34:07.965Z] 02:34:07     INFO - Failed:  1
[task 2024-01-10T02:34:07.965Z] 02:34:07     INFO - Todo:    0
[task 2024-01-10T02:34:07.966Z] 02:34:07     INFO - Mode:    e10s
[task 2024-01-10T02:34:07.966Z] 02:34:07     INFO - *** End BrowserChrome Test Results ***
[task 2024-01-10T02:34:10.848Z] 02:34:10     INFO - GECKO(3516) | Exiting due to channel error.
[task 2024-01-10T02:34:10.849Z] 02:34:10     INFO - GECKO(3516) | Exiting due to channel error.
[task 2024-01-10T02:34:10.922Z] 02:34:10     INFO - TEST-INFO | Main app process: exit 0
```
Bug: The buttons of the selection done by click/mouse drag do not show tooltips upon mouse hover
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-01-10 07:09:34+00:00
Resolved: 2024-03-30 18:45:53+00:00

**Found in**
* Nightly 123.0a1

**Affected versions**
* Nightlu 123.0a1

**Tested platforms**
* Affected platforms: macOS 13, Ubuntu 22.04 and Windows 10 x64
* Unaffected platforms: 

**Preconditions**
* 'screenshots.browser.component.enabled' is set to true in about:config

**Steps to reproduce**
1. Navigate to any website
2. Enable Screenshots by hitting the Cmd+Shift+S keys.
3. Mouse drag over the screenshots overlay.
4. Hover the mouse over the buttons of the created screenshot region: X, Copy, Download.

**Expected result**
* On mouse hover, the buttons should display tooltips: Cancel, Copy screenshot to clipboard and Download screenshot.

**Actual result**
* The buttons do not show tooltips upon mouse hover.

**Regression range**
This is not a regression, it's reproducible only when enabling the component version of Screenshots.

**Additional notes**
* Tooltips for buttons in the Save visible and Save full-screen dialogs are not affected; they are displayed on mouse hover.
* When setting 'screenshots.browser.component.enabled' to false, the issue is not reproducible.
Bug: The pixels size counter is not visible enough on the selected screenshot region
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-01-10 09:59:37+00:00
Resolved: 2024-05-07 20:07:28+00:00

**Found in**
* Nightly 123.0a1

**Affected versions**
* Nightly 123.0a1

**Tested platforms**
* Affected platforms: macOS 13, Ubuntu 22.04 and Windows 10 x64


**Preconditions**
* 'screenshots.browser.component.enabled' is set to true in about:config

**Steps to reproduce**
1. Navigate to https://en.wikipedia.org/wiki/Firefox
2. Enable Screenshots by hitting the Cmd/Ctrl+Shift+S keys.
3. Select a region by mouse dragging over the screenshots overlay. 
4. Observe the screenshot size counter.

**Expected result**
* The screenshot size counter should be clearly visible.

**Actual result**
* The screenshot size counter is not visible enough, especially when Firefox has a Light theme set. Please see the attached screenshot for more details.

**Regression range**
* This is not a regression, it's reproducible only when enabling the component version of Screenshots.

**Additional notes**
* On darker themes the issue is not as evident.
Bug: pdf date input box auto corrects DD/MM/YYYY format to American format of MM/DD/YYYY
Status: UNCONFIRMED
Priority: P3
Created: 2024-01-10 10:25:19+00:00
Resolved: 2024-05-17 11:55:23+00:00

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

Steps to reproduce:

Open a PDF which is editable and has a date input box.
Typed in a date such as 1st February 2024 in the format of DD/MM/YYYY so typed in 01/02/2024. Firefox auto-corrected this into the american format of 02/01/2024.


Actual results:

Firefox auto-corrected this into the american format of 02/01/2024.


Expected results:

What I typed should have stayed as what I typed. I checked if I could change my region but couldn't find anything.
Bug: [macOS] Items in a longer list in Firefox View are read off screen by screen reader
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-01-10 10:54:21+00:00
Resolved: 2024-02-27 15:03:37+00:00

**Found in**
- Firefox 123.0a1

**Affected versions**
- Firefox 123.0a1

**Tested platforms**
- Affected platforms: macOS 14.2.1

**Preconditions**
- Have macOS Screen Reader on

**Steps to reproduce**
1. Launch Firefox and access Firefox View
2. Access any section with lots of items
3. Scroll down in page and cycle upwards in the list with arrows or shift+tab to read the items

**Expected result**
- The items read by screen reader are visible to the user

**Actual result**
- The items read by screen reader are not visible to the user

**Additional notes**
- The issue can be seen in the [following attachment](https://drive.google.com/file/d/1JFAx8HudFLN0Xhy6XAfJQz5IawJi0_nq/view?usp=sharing)
Bug: "Firefox View" header jumps while scrolling the "Recently closed tabs"
Status: NEW
Priority: P5
Created: 2024-01-10 12:50:57+00:00
Resolved: 2024-01-10 17:45:12+00:00

**Found in**
* Beta v122.0b7

**Affected versions**
* Beta v122.0b7
* Nightly v123.0a1

**Tested platforms**
* Affected platforms: Windows 10
* Unaffected platforms: macOS 12 ARM

**Preconditions**
* have a few recently closed tabs (at least 19-20)
* resize the window to an ultrawide aspect ratio (eg: 1920x800 aka 12:5 aspect ratio)

**Steps to reproduce**
1. Open about:firefoxview-next.
2.  Go to "Recently closed tabs".
3. Scroll the items/links under "Recently closed tabs" using middle click.

**Expected result**
* The "Recently closed tabs" items are scrolled correctly, while the left "Firefox View" sidebar and its items remain static (they can be scrolled independently of "Recently closed tabs" when needed).

**Actual result**
* The "Firefox View" header on the sidebar does not remain static, making a little jump while scrolling the "Recently closed tabs" items list.
Bug: Background of titlebar icons does not update
Status: UNCONFIRMED
Priority: --
Created: 2024-01-10 13:52:43+00:00
Resolved: 2024-01-10 16:47:32+00:00

Steps to reproduce:

- Using Firefox 121.0 on Raspberry Pi OS 64-bit on a Raspberry Pi 4 (aarch64)
- I've set all the desktop colours to weird choices to make it clearer what's going wrong
- Set `browser.tabs.inTitlebar` to `2` (on Raspberry Pi OS this is set to 0 by default)
- Change focus to a window other than Firefox and then back to Firefox


Actual results:

- The top-right icons (minimise, maximise, close) render incorrectly.
- When the titlebar changes colour from inactive to active, the transparent backgrounds of the icons stay the inactive colour
- If you mouseover the icons or change Firefox tab the the icon backgrounds update and look correct.


Expected results:

- The transparent minimise/maximise/close icons should draw with the correct background colour immediately after changing window focus.
Bug: When closed, firefox will always open external links in new tabs and never new windows.
Status: NEW
Priority: P3
Created: 2024-01-10 15:50:39+00:00
Resolved: 2024-02-27 18:20:00+00:00

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

Steps to reproduce:

I launched Firefox from a link in a different app.


Actual results:

Firefox opened the link in a new tab.


Expected results:

I have set Firefox to open links in new windows instead of new tabs. When launching Firefox from a link, Firefox will ignore this setting and open the link in a new tab instead. I'm not certain how Firefox decides which window to open the tab in, but that window is often not on the desktop I am currently using so it can take an extra step to find where the tab was opened.
Bug: macos emoji & symbols input
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-01-10 16:38:57+00:00
Resolved: 2024-01-10 17:02:57+00:00

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

Steps to reproduce:

when pressing keyboard shortcuts for the emoji & symbols input, it does not work correctly. this seems to possibly be related to macos sonoma, as everything was working prior to updating. note this issue only applies to firefox, other apps continue to function correctly

- click in any text input in firefox 
- press a keyboard shortcut to show the emoji & symbols dialog: either cmd+ctrl+space, or 🌐(globe)+e 


Actual results:

- with cmd+ctrl+space, the emoji input appears but then is quickly dismissed
- with 🌐+e , the input appears but an 'e' character is entered into the textbox

note: choosing 'Emoji & Symbols' from the Edit menu appears to work correctly


Expected results:

- emoji & symbols input should pop up allowing emoji entry
Bug: Screenshots get broken when dragging the tab to a new window
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-01-10 16:48:07+00:00
Resolved: 2024-03-08 21:10:30+00:00

**Found in**
* Nightly 123.0a1

**Affected versions**
* Nightly 123.0a1

**Tested platforms**
* Affected platforms: macOS 13, Ubuntu 22.04 and Windows 10 x64.

**Preconditions**
* 'screenshots.browser.component.enabled' is set to true in about:config.

**Steps to reproduce**
1. Navigate to any website.
2. Enable Enable Screenshots by hitting the Cmd/Ctrl+Shift+S keys.
3. Drag the tab to create a new window.

**Expected result**
* A second window is created, and Screenshots should remain enabled.

**Actual result**
* The Screenshots overlay follows the tab in the second window while the buttons remain in the first window. Please see the screen recording for more details.

**Regression range**
This is not a regression, it's reproducible only when enabling the component version of Screenshots. 

**Additional notes**
* The issue does not occur when 'screenshots.browser.component.enabled' is set to false in about:config.
Bug: The last click selection is remembered after clicking away
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-01-10 18:19:27+00:00
Resolved: 2024-02-05 10:28:48+00:00

**Found in**
* Nightly 123.0a1

**Affected versions**
* Nightly 123.0a1

**Tested platforms**
* Affected platforms: macOS 13, Ubuntu 22.04 and Windows 10 x64

**Preconditions**
* 'screenshots.browser.component.enabled' is set to true in about:config.

**Steps to reproduce**
1. Navigate to this [website](https://www.vogue.in/content/most-anticipated-indian-movies-and-tv-shows-of-2024?utm_source=pocket-newtab-en-intl)
2. Enable Screenshots by pressing the Cmd/Ctrl+Shift+S keys.
3. Do a click selection of the entire upper part of the website.
4. Click outside of that selection (where no click selection can be done).
5. Click again outside of any click selection.

**Expected result**
* Nothing should happen in step 5. 

**Actual result**
* In step 5, the selection made in step 3 is remembered and visible again. For more details, please see the attached screen recording.

**Regression range**
* This is not a regression, it's reproducible only when enabling the component version of Screenshots. 

**Additional notes**
* This issue is not reproducible when 'screenshots.browser.component.enabled' is set to false in about:config.
Bug: Tab title (the tab-label in tabstrip) doesn't dynamically update to reflect URI changes that happen via pushState/location.hash (for pages that lack an explicit <title>)
Status: NEW
Priority: P3
Created: 2024-01-10 18:19:52+00:00
Resolved: 2024-02-27 16:41:17+00:00

STR:
1. Load attached testcase.
2. Hover the tab (in the tabstrip), to see the full URL being used as the tab-title.
3. Click either of the first two buttons, to change the current URL (using either location.hash or pushState)
4. Hover the tab (in the tabstrip) again.

ACTUAL RESULTS:
The URL that's shown as the tab-title is unchanged in step 4. (It doesn't update to reflect the URL update that happened in step 3.)

EXPECTED RESULTS:
The URL should change; it should remain up-to-date with the actual URL.

NOTE: If you push the third button (labeled "WORKAROUND"), that forces the tab title to catch up to reality.  (That button modifies and then restores `document.title`, which presumably clues in Firefox that it needs to re-evaluate what tab-title to show.)

This is a regression. Regression pushlog:
INFO: Last good revision: 7748cc7e9b63d86a40eb4799c0830172da579c84 (2019-11-07)
INFO: First bad revision: f414b9e6d85710f92649566c1c6511265dadd476 (2019-11-08)
INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7748cc7e9b63d86a40eb4799c0830172da579c84&tochange=f414b9e6d85710f92649566c1c6511265dadd476

Not yet sure which push there might be the thing that regressed this.

(I initially suspected a commit from bug 1492582 (one of them mentions `document.title` in its commit message), but that bug's whole patch-stack was later backed int in this same guilty-pushlog, which means it shouldn't make any difference.)
Bug: Slow rendering of PDF files with smask
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-01-10 20:06:21+00:00
Resolved: 2024-06-03 10:30:41+00:00

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

Steps to reproduce:

The attached pdf renders incorrectly in firefox. It renders correctly in most other viewers including acrobat reader, gimp, evince, chromium. Some of the text is rendered 180 degrees wrong and is placed at the wrong location.

It's also taking about 10 seconds to render it, instead of something less than 1 second for all others viewers.
Bug: Issues with Copy functionality after removing Screenshots button from Toolbar
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-01-10 20:19:51+00:00
Resolved: 2024-01-12 13:32:53+00:00

**Found in**
* Nightly 123.0a1

**Affected versions**
* Nightly 123.0a1

**Tested platforms**
* Affected platforms: macOS 13

**Preconditions**
* 'screenshots.browser.component.enabled' is set to true in about:config
* Place the Screenshots button in the Address Toolbar via Customize Toolbar.

**Steps to reproduce**
1. Go to Customize Toolbar and click on Restore Defaults.
2. Navigate to any website and enable Screenshots.
3. Do a click selection and then click on "Copy".
4. Enable Screenshots again -> click on Save visible -> click on Copy.

**Expected result**
* "Screenshots copied!" notification should be displayed each time a screenshot is copied.
* The Save visible dialog should be dismisses upon clicking the Copy button.

**Actual result**
* The "Screenshot copied!" notification is not displayed, and the Save visible dialog is not dismissed upon clicking the Copy button.

**Regression range**
* This is not a regression, it's reproducible only when enabling the component version of Screenshots.

**Additional notes**
* The Save visible dialog is properly dismissed if the pref 'screenshots.browser.component.enabled' is set to false in about:config.
Bug: Extra space added to the end of screenshot overlay when Zooming
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-01-10 21:21:48+00:00
Resolved: 2024-03-04 20:56:20+00:00

**Found in**
* Nightly 123.0a1

**Affected versions**
* Nightly 123.0a1

**Tested platforms**
* Affected platforms: macOS 13, Windows 10 x64 and Ubuntu 22.04

**Preconditions**
* 'screenshots.browser.component.enabled' is set to true in about:config

**Steps to reproduce**
1. Navigate to any website and Zoom in to 200%.
2. Enable Screenshots.
3. Scroll to the bottom of the page.
4. Press Cmd/Ctrl+0 keys to restore the zoom level to default.
5. Observe the website and the Screenshots overlay.

**Expected result**
* The website and the screenshots overlay should be correctly displayed at a 100% zoom level.

**Actual result**
* An additional gray space is added at the end of the website, and only this space is visible in the screenshots overlay. Scrolling up reveals the website again. Please see the screen recording for more details.

**Regression range**
* This is not a regression, it's reproducible only when enabling the component version of Screenshots.

**Additional notes**
* Reproducible also when Zooming only the text.
* The extra gray space at the end is not added if the pref 'screenshots.browser.component.enabled' is set to false in about:config.
Bug: The Suggest Rust backend queries all Rust providers regardless of which suggestion types are enabled
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-01-11 01:58:25+00:00
Resolved: 2024-01-11 21:12:45+00:00

The Rust backend queries the Rust component here: https://searchfox.org/mozilla-central/rev/b1a029fadaaabb333d8139f9ec3924a20c0c941f/browser/components/urlbar/private/SuggestBackendRust.sys.mjs#102-115

The Rust component takes a list of providers to query, and the backend ends up passing in all possible providers because `lazy.QuickSuggest.registeredRustSuggestionTypes` contains all possible providers. When I wrote this, I must have been thinking that `registeredRustSuggestionTypes` contains only registered *and enabled* types.

So to fix, we need to check whether the corresponding feature is enabled, plus -- since features can manage more than one type of Rust suggestion -- whether the specific suggestion type is enabled.
Bug: Significant degradation in pdf file rendering performance
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-01-11 03:52:06+00:00
Resolved: 2024-03-16 20:26:03+00:00

When I test  bug 1874013, I found that significant degradation in pdf file rendering performance.

Steps to reproduce:
1. Open https://bugzilla.mozilla.org/attachment.cgi?id=9372077

Actual results:
Rendering is slow.

Expected results:
It should render in 2-3 seconds or less.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8b60ec2f17fdf4eef3d8cd38b92d1937a9d06139&tochange=2169aa093da06570304d92967a28df4a7b58ac14
Bug: Downloads panel opens each time a screenshot is downloaded
Status: NEW
Priority: P2
Created: 2024-01-11 08:04:55+00:00
Resolved: 2024-02-26 16:59:09+00:00

**Found in**
* Nightly 123.0a1

**Affected versions**
* Nightly 123.0a1

**Tested platforms**
* Affected platforms: macOS 13, Windows 10 x64 and Ubuntu 22.04

**Preconditions**
* 'screenshots.browser.component.enabled' is set to true in about:config

**Steps to reproduce**
1. Navigate to any website.
2. Enable Screenshots and chose to download the screenshot.
3. Enable Screenshots again and chose to download the screenshot.

**Expected result**
* The Downloads panel should open only on the first time a download is ever made on that Firefox profile.

**Actual result**
* The Downloads panel opens each time a screenshot is downloaded.

**Regression range**
This is not a regression, it's reproducible only when enabling the component version of Screenshots.

**Additional notes**
* This is not reproducible when the pref 'screenshots.browser.component.enabled' is set to false in about:config.
Bug: Ensure any exceptions or unexpected data doesnt prevent restoring of all the other tabs in a session
Status: NEW
Priority: P2
Created: 2024-01-11 09:38:52+00:00
Resolved: 2024-01-29 20:44:07+00:00

STR:
1. Launch Nightly 123.0a1 (2024-01-01) and visit `about:firefoxview-next` in a normal tab.
2. Duplicate the tab.
3. Update to latest Nightly 123.0a1 (2024-01-10).
4. Restore previous session.

Shows a blank page with title "New Tab" instead of restoring previous tabs. Fails trying to create `about:firefoxview-next` which blocks session restore and causes it to be overwritten.

Browser Console error:
````
NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIAboutModule.getURIFlags] E10SUtils.sys.mjs:435

getRemoteTypeForURIObject (resource://gre/modules/E10SUtils.sys.mjs#428)
getRemoteTypeForURI (resource://gre/modules/E10SUtils.sys.mjs#384)
createTabsForSessionRestore (chrome://browser/content/tabbrowser.js#3167)
ssi_restoreWindow (resource:///modules/sessionstore/SessionStore.sys.mjs#5071)
_restoreWindowsFeaturesAndTabs (resource:///modules/sessionstore/SessionStore.sys.mjs#5245)
_restoreWindowsInReversedZOrder (resource:///modules/sessionstore/SessionStore.sys.mjs#5269)
ssi_restoreLastSession (resource:///modules/sessionstore/SessionStore.sys.mjs#4516)
ssi_restoreLastSession (resource:///modules/sessionstore/SessionStore.sys.mjs#4515)
ss_restoreLastSession (resource:///modules/sessionstore/SessionStore.sys.mjs#654)
````
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3f6550f8444c7b29d80351648aaa682f92473d34&tochange=c2654b23e1c4a78dec94da45dd8fa1c9df31456a

Regressed by Bug 1864534.
Bug: Previous tabs appear on startup even when disabled
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-01-11 10:39:03+00:00
Resolved: 2024-08-05 12:19:35+00:00

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

Steps to reproduce:

With a session containing tabs and windows, and with "Open previous windows and tabs" disabled in about:preferences, close Firefox and then re-open it


Actual results:

Firefox opens with the previous session restored


Expected results:

Firefox should open with a new empty session
Bug: Running crash tests locally shows "Welcome back" popup
Status: RESOLVED
Priority: P1
Resolution: WORKSFORME
Created: 2024-01-11 10:42:37+00:00
Resolved: 2024-05-06 16:06:45+00:00

If I run `MOZ_DISABLE_NONLOCAL_CONNECTIONS=0 mach crashtest docshell/base/crashtests/1341657.html` locally, I get the attached popup. I do not think that this should happen?