Capture JavaScript errors in your web view
Add the NativeWatch Blade script to report uncaught JavaScript errors and promise rejections through your app's local PHP integration.
By NativeWatch Updated
NativeWatch can collect uncaught JavaScript errors and unhandled promise rejections from your app's web view. Add the supplied Blade directive to the page that loads your frontend application.
Add the script before your application
Install the desktop or mobile SDK first, configure NATIVEWATCH_URL=https://native.watch, and implement diagnostic consent. Then place the directive in your root Blade layout's <head>, before application scripts:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
@nativewatchScripts
@vite('resources/js/app.ts')
</head>
<body>
@inertia
</body>
</html>
This example uses an Inertia root view; retain your own layout's other directives, attributes and scripts. The reporting directive works independently of Inertia. Include it once in the rendered root document rather than in every Vue component.
The script listens for the window's error and unhandledrejection events. It sends a compact report to a relative route in the local Laravel app, which passes it through the PHP SDK's consent, filtering and delivery pipeline. Your ingest key stays in PHP.
Keep the local endpoint relative
The default browser endpoint is /_nativewatch/browser-errors. It is local to the app, not a direct browser request to NativeWatch's hosted ingest API.
NativePHP mobile can serve pages from php://127.0.0.1. Replacing the relative endpoint with an absolute HTTP URL changes the origin and can cause the web view to block reporting. Keep the SDK's routing behavior when adding the script.
If you publish config/nativewatch.php, the browser.enabled setting controls the integration and browser.path controls the local route. Reload configuration and rendered views after changing those settings. If your app has a Content Security Policy, check that it permits the SDK's inline script and same-origin request before testing.
Test an uncaught error
In a consented development build, run the following from a temporary test button or the web-view console:
setTimeout(() => {
throw new Error('NativeWatch web-view verification');
}, 0);
Then test a rejected promise separately:
Promise.reject(new Error('NativeWatch promise verification'));
Verify the matching message, timestamp and browser crash mechanism in the receiving project. The mechanisms are webview and webview.unhandledrejection. Remove test controls before shipping.
Understand the limits
The integration captures errors delivered to those window listeners. A framework that catches and handles an error may prevent it from becoming an uncaught window error. It does not automatically report every console.error() call, and it does not establish Electron main-process or native mobile crash capture.
Stacks describe the JavaScript the web view executed. This integration does not upload or apply source maps, so production bundles may show generated filenames and locations. Message and stack sizes are bounded, repeated reports are deduplicated within the page, and the local endpoint is throttled.
Troubleshoot a missing report
First confirm the rendered page contains the script. Inspect the local POST for route, policy or network errors. A local 204 response means the controller handled the request, not that the hosted server accepted the event: consent or filtering can deliberately discard it, and delivery can wait in the outbox.
The event includes the page URL and user agent. Review URLs and exception messages for sensitive values; the default key-based scrubber does not identify every secret embedded in a URL or free-text stack.