Some actions in fxa-content-server end up displaying an alert message on the settings page. We want to be able to display those messages across the "app" boundary between the content-server front-end and new settings.
To do this we store the message in localStorage and whichever app gets to it first will display it and remove it from storage.
## Because
- The new settings page needs navigation
## This pull request
- Adds initial react reach routing and lazy loading with Suspense
- Adds a basic `FlowContainer` component that acts as container for standalone views
- There are still some rough edges around the styling that I hope can be addressed in #5028 (ie mobile view doesn't show the back arrow in correct spot)
## Issue that this pull request solves
Closes: #4899
In the new SCA payment flow, there is at least one case where we'll only
know that the subscription has been successfully paid for when the
webhook event comes in from Stripe. (i.e. client-side 3D Secure
authentication)
But, since we can't tell the difference between that and any other
cases, this PR switches all cases over to sending the download email
along with initial invoice in response to the invoice webhook event.
fixes#6175
Because:
* MySQL optimizer doesn't like using emailBounces index when using a
sub-query.
This commit:
* Splits the query into two, which then utilizes the indexes of both
tables as expected.
Closes#6064
When the graphql server fails authentication it means we need to reauthenticate the user. We do this in a slightly roundabout way by redirecting to /get_flow and having it navigate to the login page so that we can redirect_to back to /beta/settings. Once new settings is no longer in beta we ought to be able to redirect straight to /signin.
Because our assumptions about the data from gql have changed, we no longer need to worry about parts of the Account type needing a verified session, we can simplify the structure a bit.
In the future we can use `useAccount` in components to get the data they need instead of pushing down the `account` object.
This also introduces the `models` folder for organizing our types.
For testing components that `useAccount()` there's the `MockedCache` component.
## Because
- The app badges treatment won for registration and QR CAD for login
## This pull request
- Removes the QR Cad experiment logic
- Shows App Badges for Signup flows, QR Code for Signin flows, Pairing for other flows (Fx toolbar menu)
- Removes the newsletter-sync-qr-code because its not need
- Clean up tests
## Issue that this pull request solves
Closes: #5835#6147#6146#6065
Because:
* We need to use the AlertBar component throughout the project while keeping it as the first DOM element after the main tag.
This commit:
* Adds 'alert-bar-root' element and uses createPortal in AlertBar to mount
* Adds AlertBarContext for referencing the 'alert-bar-root' element
* Modifies the hook that sets focus on the element opening a modal, allowing for a 'triggerException' to allow AlertBar to take focus
* Pulls the secondary email section into its own component
Because:
- payment method for subscriptions should be updated in one place
This commit:
- move the payment method info and update form into their own section
- move CancelSubscriptionPanel into its own file
- replace 'react-test-renderer' tests with 'Testing-Library/react' ones
- make minor style and layout changes
- remove product and plan ids from payment update Amplitude events as
they are no longer associated with a subscription
* If an RP uses prompt=none with an id_token_hint, don't check against the allowed client list. This is because the user must have signed in to the RP before, otherwise the RP could not provide us a valid id_token.
* We still require an RP to be on the allowlist if they want to use
prompt=none with the user email (via either the login_hint or email
parameters).
Closes#4963, closes#6028.
This provides the base functionality needed for fxa-settings to make api calls to the auth-server. There's an `AuthContext.Provider` initialized in index.tsx and the `useAuth` hook to retrieve the client from components.
fixes#5491
Because the new settings page shows the enabled state more prominently and the data returned by this call isn't sensitive it makes more sense to lower the restriction than to burden the frontend with a more complicated design.
- removes global TTL for StripeHelper cacheManager
- sets per-method ttlSeconds based on config setting
- tests to assert the TTL changes
- some TODOs for follow up issues
fixes#6097
## Because
- We shouldn't stop a user from logging in if we detect invalid utm params
## This pull request
- Replaces the invalid utm param with `invalid` and logs a Sentry error. Hopefully we can see how often this happens and what RPs are sending
- By replacing the utm param, it allows us to still submit the metrics
## Issue that this pull request solves
Closes: #3673
Danny Coates
Les Orchard
Vijay Budhram
Vijay Budhram
Jody Heavener
Ben Bangert
Dave Justice
Jared Hirsch
Lauren Zugai
Barry Chen