PR #5732, latest commit 5dbfd89

What still needs fixing

Checked on 9 October. Seven things are left, most important first. Everything else from the earlier review is fixed; the list is at the bottom.

  1. 1The phone account menu is still a full-height panelFix before merge
  2. 2A failed request shows two error messagesFix before merge
  3. 3An error from one transfer stays on the nextFix before merge
  4. 4The same-currency transfer page can still spin foreverWorth fixing
  5. 5Changing the chart range covers the whole pageSmall
  6. 6The Unallocated funds box jumps when payments loadSmall
  7. 7The recipient edit error can just say "OK"Not new
1
Fix before merge

The phone account menu is still a full-height panel

Tapping your name on a phone opens a white panel the full height of the screen: your account and Settings at the top, Logout at the very bottom, and about 485px of empty space in between. The update moved the panel to the right edge but kept it full height.

Now
The account menu as a full-height white panel with Logout at the bottom.
Suggested
The account menu sized to its content, with Logout under Settings.

Why

On phones, .ct-account-list gets height: calc(100dvh - 60px) and Logout gets margin-top: auto, which pushes it to the bottom (account-switcher.component.scss).

Fix

// phone block, account-switcher.component.scss
.ct-account-list { height: auto; }
.ct-account-option.logout-option { margin-top: 0; }

height: auto replaces the two full-height lines. The existing max-height still caps a long account list at the screen. Tried in the browser: the menu becomes 155px tall, as in the picture.

2
Fix before merge

A failed request shows two error messages

When a page's data fails to load with a server error, the app shows its usual "Sorry, something went wrong" message, and the PR adds its own "Unable to load ..." message underneath. That's two red boxes for one problem, on every page where the PR added its own error message.

Transfer history with two stacked error messages after its request failed.
Transfer history, with its request forced to fail.

Why

The app-wide message comes from the HTTP interceptor, for any 5xx response (http-request.interceptor.ts). The PR's pages then show their own message as well.

Fix

Show one. The interceptor already skips its message for requests sent with the X-Hide-Generic-Error header (recipient.service.ts:106 does this). Send it on the requests whose page now shows its own message.

3
Fix before merge

An error from one transfer stays on the next

If a transfer fails to load and the user then opens another one, from a notification for example, the second transfer loads fine but keeps "Unable to load this content" above it.

A transfer that loaded fine, under an Unable to load this content banner left from the previous transfer.
This transfer loaded fine. The banner is left over from the transfer opened before it.

Why

The page reuses its component when only the transfer id changes. loadTrade() sets loadingFailed = true on a failure (trade-confirmation.component.ts:73) and nothing clears it for the next load. Recipient overview, rate alert overview, market order allocate and recipient approval follow the same pattern.

Fix

loadTrade(id) {
  this.loadingFailed = false;
  this.trade = undefined;
  ...

The same reset at the start of each load on the other four pages.

4
Worth fixing

The same-currency transfer page can still spin forever

For an account without a balance that supports same-currency transfers, the page never finishes loading. The update fixed the case where delivery dates fail to load, but not this one.

The same-currency transfer form with the loader still drawn over it after loading.
After loading, for an account with no same-currency balance.

Why

The update leaves selectedBalance undefined when there's no balance. isSelectedBalancePositive() then reads selectedBalance.balance (new-transfer.component.ts:192) and throws while the page renders.

Fix

Guard it (this.selectedBalance?.balance), and show a short message when there's no balance to transfer from, instead of the empty form.

5
Small

Changing the chart range covers the whole page

On a currency's page, picking a range such as 1Y draws the loader over the whole page while the chart reloads. The range buttons, Create a Rate Alert and Make a Transfer can't be clicked until it clears.

The loader drawn over the GBP to EUR page after picking 1Y.
GBP to EUR, just after clicking 1Y.

Fix

Show the loader only on the first load, or limit it to the chart and keep the old chart in place while the new range loads.

6
Small

The Unallocated funds box jumps when payments load

On a transfer's confirmation page, the payments loader sits above the Unallocated funds box. The box starts lower, then jumps up when the payments arrive.

The payments loader above the Unallocated funds box while payments load.
While payments load.

Fix

Put the payments loader below the Unallocated funds box, so the box stays where it ends up.

7
Not new

The recipient edit error can just say "OK"

When the recipient edit page fails to load, the error shows the HTTP status text. Production runs over HTTP/2, which has no status text, and Angular then reports it as "OK", so the error reads "OK". This happens today too; the PR's fallback text never shows.

Why

error.statusText || 'Unable to load recipient...' (recipient-form-page.component.ts:174 and delete-recipient-invite-page.component.ts:57). Angular fills an empty status text with "OK", so the fallback is never used.

Fix

Use the fixed message on its own, without statusText.