1787396 - The “See what’s new” button from the “MR Gratitude” modal of the existing users’ onboarding no longer opens the “Firefox View” page

Status: VERIFIED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[Simona Rosu [:srosu], Ecosystem QA]

Attachment: SeeWhat'sNew_FirefoxView.gif

[Affected versions]:

• Firefox Nightly 106.0a1 (Build ID: 20220825222149)
• Firefox Beta 105.0b3 (Build ID: 20220825185816)

[Affected Platforms]:

• macOS 12.5.1
• Windows 10 x64
• Ubuntu 20.04 x64

[Prerequisites]:

• Have the Firefox browser installed and opened.
• Have the “browser.aboutwelcome.templateMR” pref set to true.
• Have the “devtools.chrome.enabled” pref set to true.
• Have the “Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._showUpgradeDialog();” syntax copied to the clipboard.

[Steps to reproduce]:

1. Focus the Browser Console (Ctrl + Shift + J) and paste the syntax from prerequisites.
2. Press the “Enter” key.
3. Click the “Skip this step” button until the “MR Gratitude” modal is displayed.
4. Click the “See what’s new” button.
5. Observe what happens.

[Expected result]:

• The Onboarding flow ends, and the “Firefox View” page is opened in the current tab.

[Actual result]:

• The Onboarding flow ends, and the “Firefox View” page is not opened.

[Regression Window]:

• The issue is not reproducible with older Nightly 105.0a1 builds. Considering this using mozregression tools, I have found the regression range. Here are the results:
  Last good revision: 5403acde30c2edaba6dac6f0890cb413e7b75c76
  First bad revision: 6e8e2b449b07a8d5a02e75692a25353ac360d852
  Pushlog: link

From this pushlog it seems that Bug 1783049 may have introduced this behavior.

[Notes]:

• This issue is not reproducible on new users’ onboarding.
• Attached is a screen recording of the issue.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1783049

:dmosedale, since you are the author of the regressor, bug 1783049, could you take a look?
For more information, please visit auto_nag documentation.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

The bug in question changed it so that browser.tabs.firefox-view also needs to be set to true. While this is sort of a regression, it's also expected behavior - the firefox view isn't typically going to work until it is preffed on.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

If there's some place that it makes sense to (temporarily, presumably) document this, I'm happy to do so...

Comment 4

[Ed Lee :Mardak]

The pref is already true on nightly and works for about:welcome

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

What's happening here is that FirefoxViewHandler.openTab() from OPEN_FIREFOX_VIEW special message gets called from
about:welcome, on the last screen, by the primary button press, with the multistage spotlight still open.

It tries to select the FirefoxView tab, which calls into the selectedTab setter, which notices that a window-modal-global is still open, and aborts the selection.

I'm pondering possibilities around delaying the openTab() call until after the dialog closes.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: Bug 1787396 - Make upgrade dialog show FirefoxTabView, r?Mardak

Comment 7

[Ed Lee :Mardak]

Fixed with bug 1789008 https://hg.mozilla.org/mozilla-central/rev/5618f2af1761

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

In particular, the tests developer here landed as part of bug 1789008.

Comment 9

[Marius Coman [:mcoman], Ecosystem QA]

I have verified that this issue is no longer reproducible with the latest Firefox Nightly (106.0a1 Build ID - 20220908213354) installed on Windows 10 x64, macOS 11.6.5, and Linux Mint 20.2 x64. Now, I can confirm that the pinned "Firefox View" tab is opened after the “See what’s new” button is clicked.