Because:
* We want to display the amount of tax charged or included on upgrades
(if applicable)
This commit:
* Updates PlanUpgradeDetails to include tax details
* Updates SubscriptionUpgrade to pass tax details to PlanUpgradeDetails
* Updates tests for both
* Updates StoryBook for SubscriptionUpgrade to CSF and adds inclusive
and exclusive tax stories
* Adds custom hook to fetch invoicePreview and added to `routes/Product`
Closes FXA-6376
Because:
* For the invoice preview endpoint, for logged in users, do not perform
the customs.checkIpOnly.
This commit:
* Only performs the customs.checkIpOnly check if auth credentials are
not provided.
Closes FXA-6543
Because:
* We're moving the remaining FxA content-server backbone views into
React, starting with adding them to storybook.
This commit:
* Adds in the signin-confirmed/signin-verified views, and modifies the
Ready component to accept different values for the header based on
which view is being displayed
Closes #https://mozilla-hub.atlassian.net/browse/FXA-6417
Because:
- We cannot add parameters to job triggered through circleci's API
This Commit:
- Removes parameters from the `test-content-server-remote` job
Because:
- We want decrease the time it takes to deploy
This Commit:
- Adds ability to divide smoke tests
- Creates jobs that divide content server smoke tests into three parts
- Jobs can be run in parallel
- Creates a new executor for running smoke tests
- Removes mozinstall command (found in test-ci-remote.sh) since there is already a firefox browser installed in the base image
- Removes internjs argument --firefoxBinary, because there is now a firefox binary available in /usr/local/bin/firefox.
Because:
- we want to re-auth an existing session through the gql-api
This commit:
- proxy a session reauth request through the gql-api to the auth-server
Because:
* We're recreating the remaining content-server views in React and
moving them into Storybook before they go live
This commit:
* Recreates reset_password_with_recovery_key_verified in React with
metrics, tests, and l10n
Closes #https://mozilla-hub.atlassian.net/browse/FXA-6345
Because:
* Our timestamps are being recorded as from `1970-01-01` for some reason but only from the content server. We hypothesize the downstream mozlog is failing to convert this timestamp properly. Since content server is the only server that is specifying a timestamp we think if we remove it things might start working for free. Let's find out!
This commit:
* removes the timestamp
Closes FXA-6472
Because:
- We could see in Sentry that various times provided to metrics endpoint were consistently off.
This Commit:
- Creates an abstraction around the performance API to isolate some of its complexities.
- Tries to use the performance API where possible.
- Address discrepancies between performance API timestamps and system time.. The assumption that the clock used by Date and the clock used by the performance API are somehow in sync is likely the reason for the generation of erroneous data. It is very likely that there is a significant clock skew found between the monotonic clock used by the performance API and current state of the system clock. There appears to be a lot of nuance here, and the exact way this plays out depends on the OS, browser, and browser version, and if the machine has been put into sleep mode. One thing is clear, mixing the performance API timestamps and Date timestamps appears to not work very well.
- Adds support for using L2 timings, and uses these timings when possible.
- Adds a performance fallback class that can fill in for situations where the performance API is missing.
- Adds some logic around timing values that should be ignored when set to 0.
- Prefers the performance API's clock when possible, since it’s resilient to skewed metrics due to a computer being put to sleep.
- For browser’s that do not support the performance api, we will not produce timing data.
- For browser’s that do not support the performance api, we will make a best effort to produce timing data; however, if we detect the machine enters sleep mode during data collection, the data will be deemed unreliable and will not be recorded.