Description

Update SES lockdown options to improve error stacks

Set error taming to unsafe

• make error stacks also available by the error instance stack
• preserve error stack filtered content
• like we do in metamask-extension

Set stack filtering to verbose

• show full raw error info for each deep stack level
• preserve noise that the (default) concise option was removing

Follow-up to

• fix: regenerator-runtime and reenable SES (v1.1.0) on iOS (JSC) #8033

Ref: https://github.com/endojs/endo/blob/master/packages/ses/docs/reference.md#options-quick-reference

Nb: we're looking into a lockdown/repairIntrinsics option to disable touching errors entirely (for cases like ours involving React Native surfacing JS/Android/iOS errors, then later newer engine Hermes)

Related issues

• note: [Bug]: Sentry sourcemaps are incorrect #8352

Manual testing steps

Local testing in debug-mode:

• Update InitializeCore to enable SES in debug/dev mode
• Trigger an error somewhere in the app
  • new Error('test')
  • Sentry.captureException(new Error('test'))
• Check simulator
  • ensure original error preserved in call stack
  • ensure tapping error redirects to source code
• Check Sentry event
  • ensure original error preserved in call stack

But note above we're looking into a better lockdown option for React Native debug-mode,
since we disabled SES in debug-mode earlier from React Devtools interfering

Production testing:
After we merge #8373, we'll be able to ft toggle lockdown via our in-app settings menu, which will persist the choice and apply after the app has been rebooted

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've clearly explained what problem this PR is solving and how it is solved.
• I've linked related issues
• I've included manual testing steps
• I've included screenshots/recordings if applicable
• 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.
• I’ve properly set the pull request status:
  • In case it's not yet "ready for review", I've set it to "draft".
  • In case it's "ready for review", I've changed it from "draft" to "non-draft".

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.