fix: no current window and sentry context

[DaniAkash]

This pull request introduces two main types of improvements: enhanced error handling and telemetry in the browser extension, and code quality improvements in the evaluation dashboard viewer. The error handling changes ensure the extension works more reliably when no window context is available and suppresses expected errors from being reported to Sentry. The dashboard viewer code is refactored for clarity and consistency by using const instead of let for variables that are not reassigned.

Error handling and telemetry improvements:

• Added a fallback in both CreateGraph.tsx and useRunWorkflow.ts so that if creating a new Chrome window fails (e.g., all windows are closed), a new tab is created instead, improving robustness in edge cases. [1] [2]
• Updated Sentry integration to suppress reporting of expected errors (such as "The browser is shutting down" and "No current window"), and to tag errors with the extension page where they occurred for better diagnostics. Also enabled additional Sentry integrations for richer breadcrumbs. [1] [2]

Code quality improvements in the evaluation dashboard viewer:

• Refactored the JavaScript in viewer.html to consistently use const for variables that are not reassigned, improving code readability and reducing potential bugs due to accidental reassignments. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

[greptile-apps]

Greptile Summary

This PR improves extension reliability in edge cases (no open window) and reduces Sentry noise, alongside a mechanical let → const cleanup in the eval viewer. The core logic changes are sound and the Sentry integration is well-designed.

Key changes:

• CreateGraph.tsx / useRunWorkflow.ts: Add a chrome.tabs.create fallback when chrome.windows.create throws (e.g. "No current window"), preventing hard failures when all windows are closed.
• sentry.ts: Filters out expected operational errors ("The browser is shutting down", "No current window") via beforeSend, tags each event with the extension page name, and enables explicit breadcrumb capture (console, DOM, fetch, XHR).
• viewer.html: Safe let → const refactor for non-reassigned locals — no behavioral change.
• navigation.ts: Simplifies args.background === false ? false : true to args.background !== false — semantically identical.

Follow-up considerations:

• The window-creation fallback block is duplicated verbatim between CreateGraph.tsx and useRunWorkflow.ts; extracting it into a shared utility would reduce maintenance surface.
• The catch block catches all errors from chrome.windows.create, not just the expected "No current window" case, which could silently mask unexpected failures.

Confidence Score: 5/5

• Safe to merge — the fallback logic is functionally correct and the Sentry changes are additive improvements.
• All issues found are non-blocking P2 style suggestions (code duplication and broad catch scope). No logic bugs, data loss risks, or security concerns were identified. The let → const refactor and navigation.ts simplification are clean.
• CreateGraph.tsx and useRunWorkflow.ts share identical fallback logic that would benefit from extraction into a utility, and both use an overly broad catch — but neither issue is blocking.

Important Files Changed

Filename	Overview
packages/browseros-agent/apps/agent/entrypoints/app/create-graph/CreateGraph.tsx	Adds a try/catch fallback to chrome.tabs.create when chrome.windows.create fails; logic is identical to useRunWorkflow.ts — duplication and overly broad catch are worth addressing.
packages/browseros-agent/apps/agent/entrypoints/app/workflows/useRunWorkflow.ts	Same fallback pattern as CreateGraph.tsx — functionally correct but duplicates the window-creation fallback logic; same broad-catch concern applies.
packages/browseros-agent/apps/agent/lib/sentry/sentry.ts	Cleanly adds beforeSend filtering for expected noise errors, an extensionPage tag for better diagnostics, and explicit breadcrumbs configuration. Well-structured.
packages/browseros-agent/apps/eval/src/dashboard/viewer.html	Mechanical, safe let → const refactor for all non-reassigned variables across the viewer's JavaScript. No logic changes.
packages/browseros-agent/apps/server/src/tools/navigation.ts	Single-line simplification: args.background === false ? false : true → args.background !== false. Semantically equivalent and more readable.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User triggers Run / Test] --> B[chrome.windows.create\nurl: chrome://newtab]
    B -->|Success| C[backgroundWindow set]
    B -->|Throws e.g. No current window| D[catch block]
    D --> E[chrome.tabs.create\nurl: chrome://newtab]
    E -->|tab.windowId present| F[chrome.windows.get tab.windowId]
    F --> C
    E -->|tab.windowId falsy| G[backgroundWindow = undefined]
    C --> H[sendMessage with window: backgroundWindow]
    G --> H
    H --> I[Workflow / Graph run starts]

    subgraph Sentry beforeSend
        S1[Incoming event] --> S2{message in\nSUPPRESSED_ERRORS?}
        S2 -->|Yes| S3[Drop event → null]
        S2 -->|No| S4[Tag extensionPage\nfrom location.href]
        S4 --> S5[Forward to Sentry]
    end

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: packages/browseros-agent/apps/agent/entrypoints/app/create-graph/CreateGraph.tsx
Line: 262-278

Comment:
**Duplicate fallback logic — extract to shared utility**

The identical try/catch fallback block for creating a background window also appears verbatim in `useRunWorkflow.ts` (lines 104–120). Duplicating this logic means any future fix or change (e.g. adding error logging, adjusting the fallback URL) must be applied in two places.

Consider extracting a shared helper, e.g.:

```ts
// lib/chrome/createBackgroundWindow.ts
export async function createBackgroundWindow(): Promise<chrome.windows.Window | undefined> {
  try {
    return await chrome.windows.create({ url: 'chrome://newtab', focused: true, type: 'normal' })
  } catch {
    const tab = await chrome.tabs.create({ url: 'chrome://newtab', active: true })
    if (tab.windowId) {
      return chrome.windows.get(tab.windowId)
    }
  }
}
```

Then both call sites become a single `await createBackgroundWindow()`.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: packages/browseros-agent/apps/agent/entrypoints/app/create-graph/CreateGraph.tsx
Line: 269-278

Comment:
**Broad catch swallows all `chrome.windows.create` failures**

The `catch` block triggers for _any_ error from `chrome.windows.create`, not only the expected `"No current window"` case. If the call fails for a different reason (e.g. an extension permission issue or an unexpected API change), the error is silently swallowed, the code falls back to `chrome.tabs.create`, and no signal reaches Sentry or the caller. This could mask legitimate bugs.

Consider narrowing the catch to only the known expected error:

```ts
    } catch (err) {
      const isExpected = err instanceof Error && err.message.includes('No current window')
      if (!isExpected) throw err
      // Fallback when no window context is available
      const tab = await chrome.tabs.create({ url: 'chrome://newtab', active: true })
      if (tab.windowId) {
        backgroundWindow = await chrome.windows.get(tab.windowId)
      }
    }
```

The same applies to the equivalent block in `useRunWorkflow.ts`.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix: lint issues" | Re-trigger Greptile}