Description

The TPSL (Take Profit / Stop Loss) page header was intermittently positioned too high, overlapping the status bar / notch area. This occurred both when creating a TPSL from the order screen and when editing a TPSL for an open position.

Root cause: The screen relied on the shimmed SafeAreaView with edges={['top', 'bottom']} to apply the top safe area inset. The shim (SafeAreaViewWithHookTopInset) turns off the native top inset and re-applies it via a hook-based paddingTop. With the transparentModal presentation mode used by this screen, the hook-based top inset was intermittently not applied, causing the header to render too high.

Fix: Follow the same proven pattern used by PerpsOrderHeader — apply the top inset directly to the header view using useSafeAreaInsets(), and only use SafeAreaView for the bottom edge. This is deterministic and does not depend on the shimmed SafeAreaView lifecycle for transparent modals.

Changelog

CHANGELOG entry: Fixed TPSL page header overlapping the status bar area

Related issues

Fixes: TAT-3213

Manual testing steps

Feature: TPSL page header alignment

  Scenario: user creates a TPSL from the order screen
    Given the user is on the Perps order screen with an asset selected

    When user taps the TPSL / Auto close button
    Then the TPSL page opens with the header properly below the status bar / notch area

  Scenario: user edits a TPSL for an open position
    Given the user has an open Perps position with or without existing TP/SL values

    When user taps the Auto close / Edit TPSL button on the position
    Then the TPSL page opens with the header properly below the status bar / notch area

  Scenario: user repeatedly opens and closes the TPSL page
    Given the user is on the Perps order screen

    When user opens and closes the TPSL page multiple times
    Then the header is consistently aligned below the safe area every time

Screenshots/Recordings

Before

https://consensys.slack.com/archives/C092T3GPHQD/p1779353500168619

After

Header is consistently positioned below the safe area.

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.