1605738 - The "Redirect" tip is no longer triggered in the next session if you previously dismiss it temporarily and perform a search in another tab

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

[Carmen Fat [:cfat] - Ecosystem QA]

Attachment: tip dismiss.gif

[Affected versions]:

• Unbranded Beta 72.0b9 (Build ID: 20191219234059)

[Affected Platforms]:

• Windows 10 x64
• Ubuntu 16.04 x64
• Mac 10.14

[Prerequisites]:

• Have the latest Unbranded Beta 72.0b9 build installed.
• Have the “devtools.chrome.enabled” pref set to “true”.
• Run the “(async function() { let { ProfileAge } = ChromeUtils.import("resource://gre/modules/ProfileAge.jsm"); let age = await ProfileAge(); age._times = { firstUse: 1368255600000, created: 1368255600000 }; await age.writeTimes(); })();” code on the browser console.
• Have access to the stage delivery console.
• Have an active branched add-on recipe.
• Have the “security.content.signature.root_hash” pref set to "DB:74:CE:58:E4:F9:D0:9E:E0:42:36:BE:6C:C5:C4:F6:6A:E7:74:7D:C0:21:42:7A:03:BC:2F:57:0C:8B:9B:90".
• Have the "app.normandy.api_url" pref set to "https://stage.normandy.nonprod.cloudops.mozgcp.net/api/v1".
• Have the "app.normandy.dev_mode" pref set to “true”.
• Have the "app.normandy.logging.level" pref set to “0”.
• Have the "services.settings.server" pref set to "https://settings.stage.mozaws.net/v1".
• Have the "xpinstall.signatures.dev-root" pref set to “true”.
• Create a new pref named “carmentips” and set it as “true”.
• Have several tabs opened.

[Steps to reproduce]:

1. Open Firefox with the profile from prerequisites.
2. In an already opened tab navigate to https://www.google.com/ page.
3. Click anywhere on the page in order to dismiss the tip.
4. In another opened tab, perform a search using the address bar.
5. Restart the browser.
6. In an already opened tab navigate to https://www.google.com/ page.
7. Observe what happens next.

[Expected result]:

• The “Redirect” tip is displayed.

[Actual result]:

• The “Redirect” tip is not displayed.

[Notes]:

• This issue is also reproducible with the other supported search engines: Bing and DucDuckGo.
• This issue is not reproducible if, at step 4, you delete the existing URL, unfocus the address bar and only after that you perform a search.
• Attached a screen recording with the issue.

Comment 1

[Drew Willcoxon :adw]

This happens because in step 2, the extension gets an engagement-start event, but it never gets an engagement-end event. So in step 4, the extension thinks that the user started their search while a tip was showing, and therefore the user acknowledged the tip and so the extension stops showing tips.

I'm not sure how to fix this, but it's probably tricky and would require a fix in Firefox, not (only) in the add-on. It has to do with this weird state we never designed for, where the urlbar view is open and an engagement has started, but yet it doesn't have focus, so the engagement never ends "naturally" when the focus leaves the urlbar. It may be as simple as recording an engagement-end event when the view closes, but we'd need to be very careful not to regress normal engagements.

Looking at the bigger picture though, the experiment's success condition has been met in step 4: The user performed a search in the urlbar. That's the point of this experiment. I don't think it really matters that the tip technically did not appear in the very same engagement. So I will look into the possible fix I mentioned, but I'm leaning toward wontfixing this.

What do you think?

Comment 2

[Carmen Fat [:cfat] - Ecosystem QA]

Thanks for making this clear, I believe you are right with these clarifications.
Since this issue wouldn’t have been a blocker (nor a major one) for the experiment, I think it’s safe for us to set it as won’t fix due to the fact that it would require several changes in both the add-on and the browser and that these changes might cause regressions on the telemetry side.

Given the reasons above, the experiment can go live without fixing this issue.

@Drew, please mark it as won’t fix, unless you are thinking that fixing it is worth the time, the resources, and the risks of unwanted regressions.

Comment 3

[Drew Willcoxon :adw]

After investigating this more, I agree that we should wontfix this. If/when we port this experiment to the product, we should probably take a closer look at fixing this though.