1625195 - Delay in setting pref 'services.sync.username' after signing in from the "Firefox Accounts" toolbar button

Status: RESOLVED WORKSFORME

(Firefox :: Messaging System, defect, P2)

Description

[Marius Coman [:mcoman], Ecosystem QA]

Attachment: rec of the issue 2.gif

[Affected versions]:

• Firefox Nightly 76.0a1 - Build ID: 20200326093308

[Affected Platforms]:

• Windows 10 x64
• Mac 10.15.4
• Ubuntu 18.04 x64

[Prerequisites]:

• Have a new Firefox profile.
• Have a valid FxA account.

[Steps to reproduce]:

1. Open the browser with the profile from prerequisites.
2. Click the "Firefox Account" toolbar button from the top-right part of the window.
3. Sign in with the account from prerequisites and open a new tab.
4. Observe the triplets displayed in the top part of the page.

[Expected result]:

• The "Stay Alert to Data Breaches", "Browse Privately" and "Instantly Send Yourself Tabs" cards are displayed.

[Actual result]:

• The "Take Your Settings with You" card is still displayed.

[Regression Window]:

• Considering the fact that this issue is not reproducible with the Firefox Nightly version from 03/14/2020, using the mozregression tool I have managed to find the following regression:

Last good revision: f6b264818bbfc385da9010ed49dfecf2efd436f3
First bad revision: a0508ae6c037928981ac2733860b6ec84d7069ec
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f6b264818bbfc385da9010ed49dfecf2efd436f3&tochange=a0508ae6c037928981ac2733860b6ec84d7069ec

From the pushlog, it seems that bug 1508292 has caused this behavior.

[Additional Notes]:

• The "Take Your Settings with You" card is replaced after ~10 seconds.
• This issue is not reproducible if a new FxA account was created instead of logging in with an existing one.
• Attached a screen recording of the issue.

@Punam, could you please take a look over this issue?

Comment 2

[Punam Dahiya [:pdahiya]]

Debugging the issue looks like there is a visible delay in 'services.sync.username' pref getting set after signing into Sync. Sync on-boarding card replace on about:newtab gets trigerred only after 'services.sync.username' pref is set.

NI Mark for inputs and if this is a known issue in 76. Thanks!

Comment 3

[Mark Hammond [:markh] [:mhammond]]

(In reply to Punam Dahiya [:pdahiya] from comment #2)

Debugging the issue looks like there is a visible delay in 'services.sync.username' pref getting set after signing into Sync.

I doubt that's the case - there might be a delay in signing in to sync though. In other words, as soon as the browser looks like Sync is configured, that pref will be set. However, it's possible we are ending up signed in to FxA immediately, but not into sync. You can tell the different from the fxa toolbar item:

• Not signed in to anything, that toolbar has calls to sign in.
• Signed in to FxA but not sync, that toolbar has "Set Up Sync..."
• Signed in to both, that toolbar has "Sync Now"

It would be helpful to know which state the browser is in during that period.

Comment 4

[Punam Dahiya [:pdahiya]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #3)

(In reply to Punam Dahiya [:pdahiya] from comment #2)

Debugging the issue looks like there is a visible delay in 'services.sync.username' pref getting set after signing into Sync.

I doubt that's the case - there might be a delay in signing in to sync though. In other words, as soon as the browser looks like Sync is configured, that pref will be set. However, it's possible we are ending up signed in to FxA immediately, but not into sync. You can tell the different from the fxa toolbar item:

• Not signed in to anything, that toolbar has calls to sign in.
• Signed in to FxA but not sync, that toolbar has "Set Up Sync..."
• Signed in to both, that toolbar has "Sync Now"

It would be helpful to know which state the browser is in during that period.

Its the second stage , Signed in to FxA but not sync, that toolbar has "Set Up Sync..." (see attached) after FxA signin during which services.sync.username pref is not set. After a small delay about ~10 seconds users gets signed into sync and pref gets set. This delay in signing into sync is seen in 76 only and not in 74, 75, is that expected? Thanks

Comment 5

[Punam Dahiya [:pdahiya]]

Attachment: Screenshot FxA signed-in and not sync

Comment 6

[Mark Hammond [:markh] [:mhammond]]

It's not expected and I can't explain it. I believe that if the initial link to create an account doesn't include service=sync in the URL params (but it's not clear from the recording in comment 0 whether that's true or not), then it probably is expected that Sync isn't configured as part of the account creation flow - however, that doesn't explain why Sync does get configured 10 seconds later! I also can't explain why only 76 can reproduce it. Regardless, I'm (somewhat ;) confident that all of this is driven by the FxA server code based on the exact URL used by the flow.

Punam, what URL exactly is used for that flow?

Will, can you offer any insights here, or nominate anyone who can?

Comment 7

[Andrei Oprea [:andreio]]

An additional check we could do here (next to the pref check) to mitigate the issue for now is to check UIState.

    if (UIState.isReady()) {
      const {status} = UIState.get();
      if (status !== UIState.STATUS_NOT_CONFIGURED) {
        return status === UIState.STATUS_SIGNED_IN || status === UIState.STATUS_NOT_VERIFIED;
      }
    }

Comment 8

[Andrei Oprea [:andreio]]

Attachment: Bug 1625195 - Update usesFirefoxSync JEXL targeting attribute to check for Sync-UIState

Comment 9

[Punam Dahiya [:pdahiya]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #6)

It's not expected and I can't explain it. I believe that if the initial link to create an account doesn't include service=sync in the URL params (but it's not clear from the recording in comment 0 whether that's true or not), then it probably is expected that Sync isn't configured as part of the account creation flow - however, that doesn't explain why Sync does get configured 10 seconds later! I also can't explain why only 76 can reproduce it. Regardless, I'm (somewhat ;) confident that all of this is driven by the FxA server code based on the exact URL used by the flow.

Punam, what URL exactly is used for that flow?

@markh It looks like URL does include 'service=sync' in flow initiated from
a) Firefox Toolbar button (https://accounts.firefox.com/?context=fx_desktop_v3&entrypoint=fxa_discoverability_native&action=email&service=sync) and
b) click of 'Sign In to Sync' from simplified about:welcome onboarding card - Bug 1625193
(https://searchfox.org/mozilla-central/source/browser/components/newtab/content-src/lib/aboutwelcome-utils.js#60)

Will, can you offer any insights here, or nominate anyone who can?

Comment 10

[Andrei Oprea [:andreio]]

:mcoman can you please test if the bug still reproduces with dom.security.secFetch.enabled turned off?

Comment 11

[Marius Coman [:mcoman], Ecosystem QA]

Hi Andrei, I can confirm that the issue is not reproducible if the "dom.security.secFetch.enabled" pref is set to "false" in the "about:config" page.

Comment 12

[Andrei Oprea [:andreio]]

Regression confirmed so clearing myself from this and the NI.

Comment 13

[Kate Hudson :k88hudson]

Can you block this on a bug to fix the regression and deprioritize (remove P1) or close as wontfix if this isn;t a priority.

Comment 14

[Punam Dahiya [:pdahiya]]

Setting title to reflect the issue around delay in setting pref 'services.sync.username' due to delay in configuring sync after signing into FxA

See https://bugzilla.mozilla.org/show_bug.cgi?id=1625195#c4

STR:
[Prerequisites]:
Have a new Firefox profile.
Have a valid FxA account.

[Steps to reproduce]:
Open the browser with the profile from prerequisites.
Click the "Firefox Account" toolbar button from the top-right part of the window.
Sign in with the account from prerequisites
Actual Result:
Sync Pref 'services.sync.username' gets set 10 seconds later during which user sees 'Set up Sync' (See attached screenshot)

Expected Result
Sync configuration and pref 'services.sync.username' should be set immediately after FxA signin without visible delay

Comment 15

[Punam Dahiya [:pdahiya]]

I believe, this preference is used as a flag for "is sync configured" at other places. NI @wclouser to help triage and mark duplicate of any similar issue logged in FxA component. Thanks!

Comment 16

[Wil Clouser [:clouserw]]

If dom.security.secFetch.enabled toggles this behavior can we see the requests and responses being sent by the browser, including the headers? It sounds like some Sec-Fetch-* headers are getting set (which ones?) and are causing strange behavior (and then further strange behavior 10 seconds later -- maybe there is a refetch that doesn't include the headers?).

I'm not sure this is an FxA bug, but I think getting those headers would be the next step.

Comment 17

[janet [:janet]]

uncertain if this is relevant, however, https://bugzilla.mozilla.org/show_bug.cgi?id=1508292 caused a push server regression https://bugzilla.mozilla.org/show_bug.cgi?id=1623400 when the sec headers were enabled and it was caused by a the new sec headers exceeding the limit the push server was configured to accept. :ckerschb may have more info on what is being sent.

Comment 18

[Christoph Kerschbaumer [:ckerschb]]

(In reply to janet [:janet] from comment #17)

uncertain if this is relevant, however, https://bugzilla.mozilla.org/show_bug.cgi?id=1508292 caused a push server regression https://bugzilla.mozilla.org/show_bug.cgi?id=1623400 when the sec headers were enabled and it was caused by a the new sec headers exceeding the limit the push server was configured to accept. :ckerschb may have more info on what is being sent.

Unfortunately I only have limited time today hence I can't debug myself. If of any help in the meantime, the Sec-Fetch-* Headers get added here. You could add printf statements yourself which would show you what headers get set exactly. In general we set:

Sec-Fetch-Dest
Sec-Fetch-Mode
Sec-Fetch-Site
Sec-Fetch-User (as of Bug Bug 1621987

Please note that you can toggle the pref dom.security.secFetch.enabled to check if Sec-Fetch-* Headers are really the root cause.

FWIW, the problem within Bug 1623400 was that the server only accepted up to 16 request headers and including the Sec-Fetch-* request headers pushed that over the limit causing undefined behavior on the server.

Comment 19

[Mark Hammond [:markh] [:mhammond]]

(In reply to Punam Dahiya [:pdahiya] from comment #15)

I believe, this preference is used as a flag for "is sync configured" at other places. NI @wclouser to help triage and mark duplicate of any similar issue logged in FxA component. Thanks!

Note that this delay can't be reproduced (by me) when doing a "normal" login to Firefox on Nightly, where dom.security.secFetch.enabled defaults to true - so this issue must be somewhere that is exercised by the promotional "cards" but which isn't exercised by the normal user flow for logging in to an account.

Punam, can you please:

• On the same profile/account where you observed the behaviour, check you can not not observe it when logging in via the FxA toolbar or hamburger menu.

and assuming that's correct:

• come up with a test that easy for me to reproduce in a dev environment, so I can try and narrow this down a little further. Eg, some way to guarantee I see the problematic "cards" in an existing profile.

Thanks.

Comment 20

[Punam Dahiya [:pdahiya]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #19)

(In reply to Punam Dahiya [:pdahiya] from comment #15)

I believe, this preference is used as a flag for "is sync configured" at other places. NI @wclouser to help triage and mark duplicate of any similar issue logged in FxA component. Thanks!

Note that this delay can't be reproduced (by me) when doing a "normal" login to Firefox on Nightly, where dom.security.secFetch.enabled defaults to true - so this issue must be somewhere that is exercised by the promotional "cards" but which isn't exercised by the normal user flow for logging in to an account.

Punam, can you please:

• On the same profile/account where you observed the behaviour, check you can not not observe it when logging in via the FxA toolbar or hamburger menu.

and assuming that's correct:

• come up with a test that easy for me to reproduce in a dev environment, so I can try and narrow this down a little further. Eg, some way to guarantee I see the problematic "cards" in an existing profile.

Thanks.

@markh thanks for looking into it, I have verified in today nightly and there is no longer a delay in setting 'services.sync.username' pref after successful FxA login and sync card on new tab is getting replaced with next available card without any delay.

The original issue reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1625195#c0 is no longer replicable. NI QA to verify and mark issue resolved. Thanks

Comment 21

[Marius Coman [:mcoman], Ecosystem QA]

I have verified that this issue is no longer reproducible with the latest Firefox Nightly (77.0a1 Build ID - 20200426215109) installed, on Windows 10 x64, Ubuntu 18.04 x64 and Mac 10.15.4. I can confirm the "Take Your Settings with You" card is no longer displayed on the first opened tab after logging in to "Sync".

Comment 22

[Pascal Chevrel:pascalc]

(In reply to Marius Coman [:mcoman], Ecosystem QA from comment #21)

I have verified that this issue is no longer reproducible with the latest Firefox Nightly (77.0a1 Build ID - 20200426215109) installed, on Windows 10 x64, Ubuntu 18.04 x64 and Mac 10.15.4. I can confirm the "Take Your Settings with You" card is no longer displayed on the first opened tab after logging in to "Sync".

Marius, is this issue resolved then?

Comment 23

[Marius Coman [:mcoman], Ecosystem QA]

Hi Pascal, I have verified this issue and I can confirm that it is no longer reproducible. Considering this, I am closing this issue as RESOLVED - WORKSFORME. Sorry for not doing this earlier.