Skip to content

fix(fxa-settings): Show "Sign in" heading on cached signin page instead of "Enter your password#20189

Open
vbudhram wants to merge 1 commit intomainfrom
fxa-13274
Open

fix(fxa-settings): Show "Sign in" heading on cached signin page instead of "Enter your password#20189
vbudhram wants to merge 1 commit intomainfrom
fxa-13274

Conversation

@vbudhram
Copy link
Contributor

@vbudhram vbudhram commented Mar 13, 2026

Because

  • The activePageCms selector used !isPasswordNeeded as a proxy for "is cached user," so cached users who need a password got SigninPage CMS content instead of SigninCachedPage
  • CardHeader renders empty <h1> and <p> when CMS page config is undefined but shared CMS props (logo, colors) are present

This pull request

  • Adds !hasCachedAccount guard to the heading condition in Signin/index.tsx so cached users always see "Sign in" heading (password input still renders when needed)
  • Changes activePageCms to select based on hasCachedAccount instead of !isPasswordNeeded
  • Updates CardHeader/index.tsx to fall back to headingText when cmsHeadline is undefined, and skip rendering <p> when cmsDescription is missing
  • Adds storybook story for cached user with CMS but no SigninCachedPage config

Issue

Closes: https://mozilla-hub.atlassian.net/browse/FXA-13274

Checklist

  • My commit is GPG signed
  • Tests pass locally (if applicable)
  • Documentation updated (if applicable)
  • RTL rendering verified (if UI changed)

Other Information

Looking at this a bit more, ISTM that we need a dedicated page for "cached" users. The current signin page handles both, but with cms overrides it is definately confusing.

Screenshot 2026-03-13 at 4 00 40 PM

@vbudhram vbudhram requested a review from a team as a code owner March 13, 2026 20:01
// prefer the cached page config; for non-cached users, use the signin page
// config. Any of these can be undefined — CardHeader falls back to
// headingText when cmsHeadline is missing.
const activePageCms = hasCachedAccount ? cachedPageCms : signinPageCms;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about not using "activePageCms" like this to select which CMS page to use, and instead just rely on the conditional logic that already renders the two different CardHeaders? I'll admit, this const confused me when I first looked at this file... This reads more clear to me at least:

      {isPasswordNeeded && hasPassword ? (
        <CardHeader
          headingText="Enter your password"
          headingAndSubheadingFtlId="signin-password-needed-header-2"
          {...{
            cmsLogoUrl: cmsInfo?.shared.logoUrl,
            cmsLogoAltText: cmsInfo?.shared.logoAltText,
            cmsHeadline: signinPageCms?.headline,
            cmsDescription: signinPageCms?.description,
            cmsHeadlineFontSize: cmsInfo?.shared.headlineFontSize,
            cmsHeadlineTextColor: cmsInfo?.shared.headlineTextColor,
          }}
        />
      ) : (
        <CardHeader
          headingText="Sign in"
          headingTextFtlId="signin-header"
          subheadingWithDefaultServiceFtlId="signin-subheader-without-logo-default"
          subheadingWithCustomServiceFtlId="signin-subheader-without-logo-with-servicename"
          {...{
            clientId,
            serviceName,
            cmsLogoUrl: cmsInfo?.shared.logoUrl,
            cmsLogoAltText: cmsInfo?.shared.logoAltText,
            cmsHeadline: cachedPageCms?.headline,
            cmsDescription: cachedPageCms?.description,
            cmsHeadlineFontSize: cmsInfo?.shared.headlineFontSize,
            cmsHeadlineTextColor: cmsInfo?.shared.headlineTextColor,
          }}
        />
      )}

cmsInfo: MOCK_CMS_INFO,
}),
},
'CMS > Regular layout > Cached > No SigninCachedPage config'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this story should probably explicitly set the page value to be undefined, otherwise if/when we add it to that mock object later this will no longer reflect the correct state.

@vbudhram vbudhram force-pushed the fxa-13274 branch 3 times, most recently from 95954eb to 1beeb01 Compare March 14, 2026 04:55
@vbudhram vbudhram requested a review from LZoog March 16, 2026 15:39
@vbudhram vbudhram force-pushed the fxa-13274 branch 3 times, most recently from 484abbe to 24a1c99 Compare March 16, 2026 17:01

// When no SigninCachedPage is set, the non-password path falls back
// to SigninPage headline and description
// MOCK_CMS_INFO has no SigninCachedPage, so the heading falls back
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to the storybook update, this seems sorta fragile? Once we add a mock to that const this'll fail.

const title = activePageCms?.pageTitle;
const splitLayout = activePageCms?.splitLayout;
const title = (hasCachedAccount ? cachedPageCms : signinPageCms)?.pageTitle;
const splitLayout = (hasCachedAccount ? cachedPageCms : signinPageCms)
Copy link
Contributor

@LZoog LZoog Mar 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I can see why you did the activePage thing now. I didn't see this before, that we need to pass in the button text and need to do a check regardless:

                buttonText={
                  (hasCachedAccount ? cachedPageCms : signinPageCms)
                    ?.primaryButtonText
                }

I reproduced the issue on main:

Image

But in your branch currently, I see the headline issue is fixed, and there's now an issue with splitLayout (it's no showing even when it should) and the button text (showing the default instead of from the CMS). Page title probably has the same issue.

Image

I think the check against hasCachedAccount is not the check that we want, it needs to match the check that we are doing for the headline... so Since the card header conditionally renders isPasswordNeeded && hasPassword, I think we need a new constant set like this:

const showCachedView = !(isPasswordNeeded && hasPassword);

And then you can update the CardHeader logic and base the conditional page CMS object on that.

Edit just for posterity it looks like isPasswordNeeded already checks hasPassword, so I think all we need is to check isPasswordNeeded instead of hasCachedAccount.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants