1733361 - The "VPN Promo" spotlight is not displayed if Firefox is opened after the login to the captive portal is performed from another browser

Status: RESOLVED WONTFIX

(Firefox :: Messaging System, enhancement, P2)

Description

[Marius Coman [:mcoman], Ecosystem QA]

Attachment: rec of the issue .gif

[Affected versions]:

• Firefox Beta 93.0 - Build ID: 20210927210923

[Affected Platforms]:

• Windows 10 x64

[Prerequisites]:

• Have a profile with the following prefs in the "about:config" page:
  • messaging-system.rsexperimentloader.collection_id set to nimbus-preview.
  • browser.search.region set to US.
• You are enrolled in the "captive-portal-vpn-info-experiment".
• Have a captive portal connection.
• Have another browser set as default (E.G. Google Chrome).
• The Firefox browser is not opened.

[Steps to reproduce]:

1. Connect to the captive portal.
2. Perform the login to the captive portal from the "Google Chrome" browser.
3. Open the Firefox browser with the profile from prerequisites.
4. Observe the behavior.

[Expected result]:

• The "VPN Promo" spotlight is successfully triggered.

[Actual result]:

• The "VPN Promo" spotlight is not triggered.

[Notes]:

• This issue is still reproducible after browser restart.
• This issue is NOT reproducible if the Firefox browser is opened while the login action is performed from another browser.
• Attached a screen recording of the issue.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

As discussed elsewhere, although early discussions made us hopeful that this would Just Work (like it does on Linux), from what I've been able to find, Windows doesn't make it straightforward.

Which is to say, the docs for one Windows API that's related to this make it sound like that API may or may not improve matters:

This doesn't guarantee detection of a captive portal. UWP apps should also test if the captive portal can be reached using a URL for the captive portal, or by attempting access to a public web site which will then redirect to the captive portal when Windows reports LocalAccess as the current NetworkConnectivityLevel.

Here is another thing blog post that might or might not help that appears to use older APIs .

In any of those cases, this is more an enhancement than just a bug fix.

Comment 2

[Yasmin S]

Dan does this still need to be tracked is the experiment still running ?

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

Yes, because that promo will be rolled out as a feature in 96.

Comment 5

[Jason Prickett]

Is this still an issue?

Comment 6

[Emily McMinn :emcminn]

The strings for this message landed in m-c, but I don't think the message ever made it out of experimentation.

The issue I think would have be caused by the message being triggered on captivePortalLogin which is an event, instead of some sort of system state. With the login event happening in the other browser, there's nothing to trigger the message to show in Firefox.

I'm going to close this as WONTFIX; if we decide to implement this kind of message again we can look at reworking the trigger.