av9ash/GitBugs huggingface dataset:
Bug: Intermittent browser/base/content/test/captivePortal/browser_captivePortal_certErrorUI.js | Test timed out | Found a tab after previous test timed out
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-06-14 22:27:07+00:00
Resolved: 2021-01-18 06:16:03+00:00

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

---

[task 2020-06-14T21:50:01.317Z] 21:50:01     INFO - Clicking the Open Login Page button
[task 2020-06-14T21:50:01.317Z] 21:50:01     INFO - Buffered messages finished
[task 2020-06-14T21:50:01.317Z] 21:50:01     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/captivePortal/browser_captivePortal_certErrorUI.js | Test timed out - 
[task 2020-06-14T21:50:01.318Z] 21:50:01     INFO - GECKO(1974) | MEMORY STAT | vsize 3242MB | residentFast 356MB | heapAllocated 97MB
[task 2020-06-14T21:50:01.318Z] 21:50:01     INFO - TEST-OK | browser/base/content/test/captivePortal/browser_captivePortal_certErrorUI.js | took 90050ms
[task 2020-06-14T21:50:01.318Z] 21:50:01     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-06-14T21:50:01.318Z] 21:50:01     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/captivePortal/browser_captivePortal_certErrorUI.js | Found a tab after previous test timed out: https://expired.example.com/ - 
[task 2020-06-14T21:50:01.318Z] 21:50:01     INFO - GECKO(1974) | [Child 2186: Main Thread]: I/DocShellAndDOMWindowLeak ++DOCSHELL 0x7f4333fb0400 == 1 [pid = 2186] [id = {74544de5-b098-4565-bd2e-01416417b8dc}]
[task 2020-06-14T21:50:01.318Z] 21:50:01     INFO - GECKO(1974) | [Child 2186: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 1 (0x7f434f593350) [pid = 2186] [serial = 12] [outer = (nil)]
[task 2020-06-14T21:50:01.319Z] 21:50:01     INFO - GECKO(1974) | [Child 2186: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 2 (0x7f4333fb2400) [pid = 2186] [serial = 13] [outer = 0x7f434f593350]
[task 2020-06-14T21:50:01.319Z] 21:50:01     INFO - checking window state
Bug: UI glyphs disappear when changing ui.prefersReducedMotion pref
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2020-06-15 00:59:41+00:00
Resolved: 2021-02-02 21:06:49+00:00

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

Steps to reproduce:

1. Open Nightly
2. Go to `about:config`
3. Change the `ui.prefersReducedMotion` preference to either 1 or 0 depending on its current value.


Actual results:

Icons disappear when the preference is changed. There is no correlation between the value it is changing to and the glyphs disappearing; it happens during the act of the value changing. Please see the attached screen recording, showing a fresh browser start and reproduction of the issue.


Expected results:

UI icons should not disappear.
Bug: Intermittent browser/extensions/doh-rollout/test/browser/browser_trrMode_migration.js | Found the expected trrselect event. - Got 2, expected 1
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2020-06-15 01:14:55+00:00
Resolved: 2020-07-12 22:26:41+00:00

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

---

>[task 2020-06-15T00:08:57.388Z] 00:08:57     INFO - TEST-START | browser/extensions/doh-rollout/test/browser/browser_trrMode_migration.js
[task 2020-06-15T00:08:57.645Z] 00:08:57     INFO - TEST-INFO | started process screentopng
[task 2020-06-15T00:08:57.837Z] 00:08:57     INFO - TEST-INFO | screentopng: exit 0
[task 2020-06-15T00:08:57.837Z] 00:08:57     INFO - Buffered messages logged at 00:08:57
[task 2020-06-15T00:08:57.837Z] 00:08:57     INFO - Entering test bound setup
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - Leaving test bound setup
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - Entering test bound testTRRModeMigration
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - TEST-PASS | browser/extensions/doh-rollout/test/browser/browser_trrMode_migration.js | TRR mode is 2 - 
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - Buffered messages finished
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - TEST-UNEXPECTED-FAIL | browser/extensions/doh-rollout/test/browser/browser_trrMode_migration.js | Found the expected trrselect event. - Got 2, expected 1
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - Stack trace:
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - chrome://mochikit/content/browser-test.js:test_is:1327
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - chrome://mochitests/content/browser/browser/extensions/doh-rollout/test/browser/head.js:checkTRRSelectionTelemetry:130
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - TEST-PASS | browser/extensions/doh-rollout/test/browser/browser_trrMode_migration.js | The event records the expected decision - 
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-06-15T00:08:57.838Z] 00:08:57     INFO - TEST-UNEXPECTED-FAIL | browser/extensions/doh-rollout/test/browser/browser_trrMode_migration.js | Found the expected heuristics event. - Got 2, expected 1
[task 2020-06-15T00:08:57.839Z] 00:08:57     INFO - Stack trace:
[task 2020-06-15T00:08:57.839Z] 00:08:57     INFO - chrome://mochikit/content/browser-test.js:test_is:1327
[task 2020-06-15T00:08:57.840Z] 00:08:57     INFO - chrome://mochitests/content/browser/browser/extensions/doh-rollout/test/browser/head.js:checkHeuristicsTelemetry:170
[task 2020-06-15T00:08:57.842Z] 00:08:57     INFO - TEST-PASS | browser/extensions/doh-rollout/test/browser/browser_trrMode_migration.js | The event records the expected decision - 
[task 2020-06-15T00:08:57.843Z] 00:08:57     INFO - TEST-PASS | browser/extensions/doh-rollout/test/browser/browser_trrMode_migration.js | Got the expected reason. -
Bug: `The log 'Services.Common.RESTRequest' is configured to use the preference 'services.common.log.logger.rest.request'` message often printed when sync configured
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-06-15 04:35:01+00:00
Resolved: 2020-06-15 09:29:48+00:00

This has been annoying me for a while so thought I should just fix it.
Bug: Firefox should retry getting a push subscription if it failed in the past
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-06-15 07:24:46+00:00
Resolved: 2020-06-16 15:53:03+00:00

If we fail to get a push subscription as part of the signin/signup flow, we will retry a number of times (depending on verified state etc), but if we always fail but the account becomes fully verified, we appear to never retry.

This is probably as simple as checking if we have *any* subscription rather than just for expiry, in https://searchfox.org/mozilla-central/source/services/fxaccounts/FxAccountsDevice.jsm#226
Bug: Moving Google Meet tab to a new window fails and breaks rendering
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-15 09:22:20+00:00
Resolved: 2020-06-22 12:46:42+00:00

While in a Google Meet call, I wanted to move the tab with the call to a different window. First, the extraction seems to fail: the tab drifts back to its original window. Second, the tab bar rendering seems to be broken after this, see attachment.

Using Nightly on macOS with WebRender enabled (but at least some of this doesn't seem to be related to WebRender).
Bug: TLS warning screen does not use localised date
Status: VERIFIED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-15 11:34:35+00:00
Resolved: 2020-06-18 11:03:36+00:00

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

Steps to reproduce:

Step 1: Navigate to URL with an expired TLS certificate 
Step 2: Security risk warning screen is show


Actual results:

Date format is in MM/DD/YYYY


Expected results:

Date format should be in DD/MM/YYYY
Bug: Uncaught TypeError when clicking in sidebar of about:policies
Status: VERIFIED
Priority: P5
Resolution: FIXED
Created: 2020-06-15 11:35:59+00:00
Resolved: 2020-07-22 08:49:18+00:00

Clicking on one of the two available sections keeps raising errors in the console.

```
Uncaught TypeError: can't access property "textContent", button.children[1] is undefined
    show chrome://browser/content/policies/aboutPolicies.js:406
    onload chrome://browser/content/policies/aboutPolicies.js:366
    onload chrome://browser/content/policies/aboutPolicies.js:366
    EventHandlerNonNull* chrome://browser/content/policies/aboutPolicies.js:352
```
Bug: "Basic Page Style" entry in the View > Page Style menu doesn't work reliably
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2020-06-15 13:02:08+00:00
Resolved: 2020-07-07 10:23:13+00:00

I have the following stylesheets defined in the `head` section of the HTML document:

```
<link rel="stylesheet" href="css/main.css" media="screen" />
<link rel="alternate stylesheet" href="css/high-contrast.css" media="screen"
        title="High Contast" />
<link rel="alternate stylesheet" href="css/dyslexia.css" media="screen"
        title="Open-Dyslexic" />
```

When I load the page in Firefox, the `View > Page Style` menu is populated by these alternate stylesheets. Also, switching to any of the alternates does update the page as expected.

When switching back to `Basic Page Style` however, the original page style is not reflected. It seems that whatever the last alternate selected stylesheet was, is assigned to `Basic Page Style`. The only way to get back to the original styling is to reload the page.

The attache video demonstrates the problem described.
Bug: Empty Content-Type with XCTO: nosniff will not offer "Open in Nightly" for PDFs
Status: REOPENED
Priority: P3
Created: 2020-06-15 13:37:53+00:00
Resolved: 2024-02-27 17:08:03+00:00

Reproducible testcase: https://didattica.polito.it/pls/portal30/sviluppo.pkg_apply_admin.download_bando?p_id_bando=14836&p_tipo=bando

The server returns a PDF file, but with an empty Content-Type in the HTTP response. Firefox correctly identifies the file as a PDF, but otherwise acts as if it were a text file: it does not show an "Open in Nightly" option nor will it suggest to open it with PDF viewers (it will suggest a text editor). I verified that if I manually fix the Content-Type header with a proxy, the bug does not occur.

Furthermore, Nightly identifies the file as a PDF, but Release does not (it detects a text file instead). I believe this is an intended enhancement though.

HTTP response:
```
HTTP/1.1 200 OK
Date: Mon, 15 Jun 2020 12:23:26 GMT
Server: ATS/3.3.1
Cache-Control: max-age=0
Content-Length: 496941
Content-Disposition: attachment; filename="bando-det-disat-carbone-2-699.pdf"; title="bando-det-disat-carbone-2-699.pdf"
[misc...]
Content-Type: 
Content-Language: en
Age: 0
[misc...]
```
Bug: Browser language switcher results are not highlighted in a dropdown after the second click on it
Status: NEW
Priority: P5
Created: 2020-06-15 13:46:17+00:00
Resolved: 2021-09-27 17:22:43+00:00

**Affected versions**
* Fx 78.0b7
* Fx 68.9.0esr
* Fx 76.0

**Affected platforms**
* Windows 10 x64
* macOS 10.15
* Ubuntu 16.04 x86

**Steps to reproduce**
1. Open about:preferences
2. On Search text field enter "search" .
3. On Language section click on "English (United States)" button that brings up a dropdown menu.
4. Click on "Search for more languages...", the last item from dropdown.
5. Close the "Firefox Language Settings" page.
6. Click again on dropdown.

**Expected result**
* The searched word is correctly highlighted in dropdown (see. Before.png)

**Actual result**
* The searched word is no longer highlighted in dropdown (see. AfterClickAgainOnDropdown.png)

**Regression range**
  * I will come back with regression range ASAP.

**Notes**
* In Fx 72.0.2, Fx 73.0, Fx 75.0 the searched word is not selected even at the first click on dropdown.
* There are differences between Firefox Nightly ui and Firefox Beta ui, regarding Language section from about:preferences.
Bug: .local domain urls are searched but not resolved
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-15 14:40:12+00:00
Resolved: 2020-06-28 09:01:07+00:00

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

Steps to reproduce:

open internal url e.g. site.domain.local 


Actual results:

site.domain.local is seached instead of resolved. 


Expected results:

site.domain.local should be resolved and opened.
Bug: Themes are synced as disabled to another profiles
Status: NEW
Priority: P3
Created: 2020-06-15 16:57:25+00:00
Resolved: 2025-03-05 19:17:41+00:00

Environment: 
Multiple profiles created on FF 77.0.1, using Windows 10x64. 
Sync failed too between FF77.0.1 and Nightly on MacOS 79.0a1

Steps to reproduce:
1. Open 2 FF new profiles and login with same FXA
2. Install any theme from addons.mozilla.org to one of the profiles
3. Sync on both profiles

Expected results:
Themes are synced between profiles and they are Enabled on both profiles

Actual results:
Themes are synced in about:addons , Themes section, but they are DISABLED for the second profile 
Sync failure is seen about:sync-log (install https://addons.mozilla.org/en-US/firefox/addon/about-sync/ in order to see these logs)

NOTES:
I will attach the sync logs
Bug: Text selection in address bar not copied to X buffer
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-15 17:14:27+00:00
Resolved: 2020-06-17 14:27:16+00:00

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

Steps to reproduce:

I have a page whose URL I wish to copy using the X buffer.  I click on the address bar, resulting in the URL being selected.  

At this point I expect that the URL text is now in the X buffer and can be pasted with middle click.  


Actual results:

The text is not in the X buffer and the selection must be manually cleared then reselected.  


Expected results:

The text should have been copied to the X buffer immediately on automatic selection.
Bug: Broken Bookmark Search
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-15 23:28:39+00:00
Resolved: 2020-06-20 03:49:03+00:00

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

Steps to reproduce:

Opened "Bookmark" pop-down

Selected "Bookmarks" , then "Search Bookmarks"


Actual results:

You cannot actually search the bookmarks (as of my last update).

The "Search Bookmarks" does not even look at the bookmarks - it insists that you use the default search engine - WHICH HAS NOTHING TO DO WITH BOOKMARKS. 


Expected results:

ONLY the "Bookmarks" should have been searched (they were searched until the last beta update).

This is no longer a usable function.

Should I downgrade to the last functional beta (or real release & take myself off of the beta release channel)?
Bug: Gamepads don't work in Flatpak version
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-16 04:05:39+00:00
Resolved: 2020-07-09 12:03:09+00:00

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

Steps to reproduce:

I have the Flatpak version installed already. I also unpacked the regular tarball binary release. I tested gamepadviewer.com in both versions.


Actual results:

In the Flatpak version, I can mash all the inputs I want but nothing happens. In the binary tarball version, after I make an input, I am able to select "Player 1" from the menu that appears at the top and see inputs.


Expected results:

The gamepad is read in the Flatpak version just the same as the binary tarball version.
Bug: IDN homograph spoofing by mixing latin with accented latin extended glyphs
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-16 04:07:25+00:00
Resolved: 2023-05-23 04:25:55+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36

Steps to reproduce:

We are researchers from the University of Illinois. We find some issues with Chrome’s IDN policies. Chrome is currently displaying Punycode for internationalized domain names (IDN) that are created to impersonate other popular domain names or brands (i.e., IDN homograph). However, we find that certain IDN homograph is consistently displayed in Unicode (e.g., those using “Latin Extended-A”, those imprisoning .gov or .mil domain names, etc.).

Examples: 
tumbır.com 
paypaī.com 
militarỹonesource.mil




Actual results:

These domains are displayed as Unicode, may deceive users. 
I attached a list of examples of such homograph IDNs that have this issue. 


Expected results:

Expect to display Punycode
Bug: 1.24 - 3.06% ts_paint_webext (windows10-64-shippable) regression on push 6be570e963dec97af0d0ceffd0b3526d284304aa (Wed June 10 2020)
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-06-16 06:36:53+00:00
Resolved: 2020-07-08 14:10:30+00:00

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

Regressions:

   3%  ts_paint_webext windows10-64-shippable opt e10s stylo     304.92 -> 314.25
   1%  ts_paint_webext windows10-64-shippable opt e10s stylo     309.83 -> 313.67


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perf.html#/alerts?id=26228), 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: The cursor is flickering when sharing an entire screen on Windows
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-16 10:16:04+00:00
Resolved: 2020-06-18 02:07:52+00:00

**Note**
* When the user shares an entire screen, he will notice that the cursor has a slight flicker.

**Affected versions**
* Nightly v79.0a1
* Beta v78.0b7
* Release v77.0.1
* ESR v68.9.0esr

**Affected platforms**
* Windows 10
* Windows 7

**Steps to reproduce**
1. Engage in a (Zoom) video call.
2. Allow mic and camera permissions.
3. Click the web-app's "Share Screen" button.
Observe:  The screen-sharing permission door-hanger is displayed.
4. Select a screen option from the drop-down.
Observe: The cursor starts flickering.
5. Click on the "Allow" button

**Expected result**
* The cursor is properly displayed. No flicker is visible.

**Actual result**
* The cursor has a visible flicker.

**Regression range**
* This is NOT a recent regression.

**Additional notes**
* Reproduced with Zoom and jump.chat.
* The flicker appears to be more observable when the cursor is on the primary monitor, the higher refresh rate monitor (144 Hz).
* This issue is only reproducible on Windows.
Bug: Protections ETP on/off tooltip overwrites builtin description element
Status: NEW
Priority: P3
Created: 2020-06-16 12:15:40+00:00
Resolved: 2020-07-01 13:01:47+00:00

```html
        <tooltip id="protections-popup-not-blocking-why-etp-on-tooltip" data-l10n-id="protections-panel-not-blocking-why-etp-on-tooltip"></tooltip>
        <tooltip id="protections-popup-not-blocking-why-etp-off-tooltip" data-l10n-id="protections-panel-not-blocking-why-etp-off-tooltip"></tooltip>
```

both use fluent to set their `textContent`, but the normal way of setting the contents of a tooltip node is to set their `label` attribute, which gets reflected into the builtin `description` element that [gets inserted by the C++ XUL tooltip implementation](https://searchfox.org/mozilla-central/rev/027893497316897b8f292bde48dbb6da2391a331/dom/xul/XULTooltipElement.cpp#28-42).
Bug: Fixed-positioned elements (e.g. headers/footers) are included in screenshots, at unexpected places, if you happen to scroll while capturing the screenshot
Status: NEW
Priority: P2
Created: 2020-06-16 14:24:28+00:00
Resolved: 2024-10-09 10:51:44+00:00

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

Steps to reproduce:

1. Open any page with fixed header (for example facebook or https://community.wanikani.com/t/userscript-wanikani-heatmap/34947/627)
2. Open screenshot tool
3. Make a custom selection that is bigger then screen height and requires scrolling the view
4. Try to copy/save screenshot without the header in the middle


Actual results:

I get a clean screenshot without the header in the middle


Expected results:

The problem stems from the header rendered in the middle. We could just scroll up so that our selection start just below the header (so it wouldn't be included in the screenshot) but it's impossible to do because action buttons are at the bottom of the selection area which requires scrolling down so the header overlaps the selection (which hides behind upper edge of the viewport).

Ideally action buttons should hover *within selection* and *within viewport*
Bug: The multistage "about:welcome" page should not redirect to the "about:newtab" one after the "Import Wizard" flow is canceled
Status: RESOLVED
Priority: P2
Resolution: WONTFIX
Created: 2020-06-16 15:00:44+00:00
Resolved: 2023-04-01 06:28:11+00:00

**[Affected versions]:**
- Firefox Beta 78.0b7 - Build ID: 20200612174529
- Firefox Nightly 79.0a1 - Build ID: 20200616092900

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

**[Prerequisites]:**
- Have a Firefox profile with the following pref in the "about:config" page:
   - "browser.aboutwelcome.overrideContent" set to `{"id": "multi-stage-welcome-importable","template": "multistage","screens": [{"id": "AW_GET_STARTED","order": 0,"content": {"title": { "string_id": "onboarding-welcome-header" }, "subtitle": "The fast, safe, and private browser that's backed by a non-profit.", "primary_button": {"label": "Start Setup","action":{"navigate": true}}, "secondary_button": {"text": "Have an account?", "label": "Sign in","position": "top", "action":{"type": "OPEN_URL","addFlowParams": true, "data":{"args": "https://accounts.firefox.com/?service=sync&action=email&context=fx_desktop_v3&entrypoint=activity-stream-firstrun&style=trailhead","where": "current"}}}}},{"id": "AW_IMPORT_SETTINGS","order": 1,"content": {"title": "Import your passwords, bookmarks,\u00a0and more","subtitle": "Coming from another browser? It's easy to bring everything to Firefox.","tiles": {}, "primary_button": {"label": "Start Import", "action":{"type": "SHOW_MIGRATION_WIZARD","navigate": true}},"secondary_button": {"label": "Not now","action":{"navigate": true}}}}]}`

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Navigate to the "about:welcome" page and click the "Start Setup" button.
3. Click the "Start Import" button.
4. Click the "Cancel" button from the "Import Wizzard" and observe the behavior.

**[Expected result]:**
- The "Import Wizzard" is closed and the "about:welcome" page is displayed.
	
**[Actual result]:**
- The "Import Wizzard" is closed and the "about:welcome" page redirects to the "about:newtab" one.

**[Notes]:**
- Considering the fact that the import flow may be mistakenly canceled by a user that is new to Firefox, we should still display the "about:welcome" page instead of redirecting to the "about:newtab" one.
- This behavior is also reproducible with the "Dynamic" branch of the multistage "about:welcome" page.
- Attached a screen recording of the issue.