electron/modules/typed-event-emitter.ts (1)

155-163: 🛠️ Refactor suggestion

destroy() should be idempotent

Throwing when destroy() is called twice can crash listeners that legitimately call it in both explicit teardown and the "closed" event.
Better to convert the guard into a no‑op:

-    if (this.isDestroyed) {
-      throw new Error("Window already destroyed!");
-    }
+    if (this.isDestroyed) {
+      return; // already cleaned up
+    }

This makes the class easier to use and reduces the chance of unhandled exceptions during shutdown sequences.

electron/sessions/spaces.ts (1)

30-44: 🛠️ Refactor suggestion

Validate & type‑check datastore contents

reconcileSpaceData() trusts arbitrary datastore values and manually applies fall‑backs. Zod has already defined SpaceDataSchema; use it to parse/validate and surface bad data early:

-  return {
-    name: data.name ?? defaultName,
-    ...
-  };
+  return SpaceDataSchema.parse({
+    name: data.name ?? defaultName,
+    profileId,
+    ...data
+  });

This eliminates silent schema drift and forces callers to fix corrupted records instead of propagating them.

vite/.gitignore (1)

27-27: Correct the UI directory ignore pattern

The previous entry mistakenly included a leading hyphen. Changing to ui/* properly ignores the ui directory and its contents. As a small improvement, you can simplify this to ignore the directory directly:

-ui/*
+ui/

.gitignore (1)

138-145: Exclude macOS metadata and legacy artifacts

Adding .DS_Store under a dedicated # macOS header prevents OS-specific files from being committed. Ignoring legacy folders (extensions, vite-old, vite-old-2, and electron/browser/_old) also helps keep the repo clean. For clarity and consistency, consider anchoring directory patterns and using trailing slashes:

-# macOS
-.DS_Store

-extensions/*
-vite-old
-vite-old-2
-electron/browser/_old
+# macOS
+.DS_Store

+extensions/
+vite-old/
+vite-old-2/
+electron/browser/_old/

vite/public/chrome-dino-game/appmanifest.json (1)

1-37: Well-structured web app manifest with all essential properties

The manifest follows PWA standards with appropriate properties for the Chrome Dino game. All required fields are present with correct formatting and a good set of icons at various resolutions.

One minor enhancement you might consider:

 {
 	"name": "Chrome Dino",
 	"short_name": "Chrome Dino",
 	"description": "Dino game. A pixelated dinosaur dodges cacti and pterodactyls as it runs across a desolate landscape.",
 	"version": "2.0",
 	"start_url": "index.html",
 	"display": "fullscreen",
 	"orientation": "any",
 	"background_color": "#ffffff",
+	"theme_color": "#ffffff",
 	"icons": [

vite/public/chrome-dino-game/scripts/strings.js (1)

1-2: Consider improving code readability while maintaining functionality

The code correctly defines and assigns localized strings for the Chrome Dino game. The pageData object contains all necessary game configuration including accessibility labels, image paths, and UI text.

For better maintainability, consider formatting the JSON object with proper indentation:

-var pageData = {"altGameCommonImage1x":"images/default_100_percent/offline/100-olympic-firemedal-sprites.png","altGameCommonImage2x":"images/default_200_percent/offline/200-olympic-firemedal-sprites.png","dinoGameA11yAriaLabel":"","dinoGameA11yGameOver":"Game over, your score is $1.","dinoGameA11yHighScore":"Your highest score is $1.","dinoGameA11yJump":"Jump!","dinoGameA11ySpeedToggle":"Start slower","dinoGameA11yStartGame":"Game started.","enableAltGameMode":false,"errorCode":"","fontfamily":"'Segoe UI', Tahoma, sans-serif","fontsize":"75%","heading":{"hostName":"dino","msg":"Press space to play"},"iconClass":"icon-offline","language":"en","textdirection":"ltr","title":"chrome://dino/"};
+var pageData = {
+  "altGameCommonImage1x": "images/default_100_percent/offline/100-olympic-firemedal-sprites.png",
+  "altGameCommonImage2x": "images/default_200_percent/offline/200-olympic-firemedal-sprites.png",
+  "dinoGameA11yAriaLabel": "",
+  "dinoGameA11yGameOver": "Game over, your score is $1.",
+  "dinoGameA11yHighScore": "Your highest score is $1.",
+  "dinoGameA11yJump": "Jump!",
+  "dinoGameA11ySpeedToggle": "Start slower",
+  "dinoGameA11yStartGame": "Game started.",
+  "enableAltGameMode": false,
+  "errorCode": "",
+  "fontfamily": "'Segoe UI', Tahoma, sans-serif",
+  "fontsize": "75%",
+  "heading": {
+    "hostName": "dino",
+    "msg": "Press space to play"
+  },
+  "iconClass": "icon-offline",
+  "language": "en",
+  "textdirection": "ltr",
+  "title": "chrome://dino/"
+};

vite/public/chrome-dino-game/styles/interstitial_core.css (1)

1-15: Consolidate duplicate CSS variable definitions

The CSS file has duplicate variable definitions in both :root and body selectors, which creates unnecessary redundancy.

Consider consolidating the duplicate CSS variables by keeping them only in the :root selector:

:root {
  --background-color: #fff;
  --google-blue-100: rgb(210, 227, 252);
  --google-blue-300: rgb(138, 180, 248);
  --google-blue-600: rgb(26, 115, 232);
  --google-blue-700: rgb(25, 103, 210);
  --google-gray-100: rgb(241, 243, 244);
  --google-gray-300: rgb(218, 220, 224);
  --google-gray-500: rgb(154, 160, 166);
  --google-gray-50: rgb(248, 249, 250);
  --google-gray-600: rgb(128, 134, 139);
  --google-gray-700: rgb(95, 99, 104);
  --google-gray-800: rgb(60, 64, 67);
  --google-gray-900: rgb(32, 33, 36);
+  --error-code-color: var(--google-gray-700);
+  --heading-color: var(--google-gray-900);
+  --link-color: rgb(88, 88, 88);
+  --popup-container-background-color: rgba(0,0,0,.65);
+  --primary-button-fill-color-active: var(--google-blue-700);
+  --primary-button-fill-color: var(--google-blue-600);
+  --primary-button-text-color: #fff;
+  --quiet-background-color: rgb(247, 247, 247);
+  --secondary-button-border-color: var(--google-gray-500);
+  --secondary-button-fill-color: #fff;
+  --secondary-button-hover-border-color: var(--google-gray-600);
+  --secondary-button-hover-fill-color: var(--google-gray-50);
+  --secondary-button-text-color: var(--google-gray-700);
+  --small-link-color: var(--google-gray-700);
+  --text-color: var(--google-gray-700);
}

body {
-  --background-color: #fff;
-  --error-code-color: var(--google-gray-700);
-  --google-blue-100: rgb(210, 227, 252);
-  --google-blue-300: rgb(138, 180, 248);
-  --google-blue-600: rgb(26, 115, 232);
-  --google-blue-700: rgb(25, 103, 210);
-  --google-gray-100: rgb(241, 243, 244);
-  --google-gray-300: rgb(218, 220, 224);
-  --google-gray-500: rgb(154, 160, 166);
-  --google-gray-50: rgb(248, 249, 250);
-  --google-gray-600: rgb(128, 134, 139);
-  --google-gray-700: rgb(95, 99, 104);
-  --google-gray-800: rgb(60, 64, 67);
-  --google-gray-900: rgb(32, 33, 36);
-  --heading-color: var(--google-gray-900);
-  --link-color: rgb(88, 88, 88);
-  --popup-container-background-color: rgba(0,0,0,.65);
-  --primary-button-fill-color-active: var(--google-blue-700);
-  --primary-button-fill-color: var(--google-blue-600);
-  --primary-button-text-color: #fff;
-  --quiet-background-color: rgb(247, 247, 247);
-  --secondary-button-border-color: var(--google-gray-500);
-  --secondary-button-fill-color: #fff;
-  --secondary-button-hover-border-color: var(--google-gray-600);
-  --secondary-button-hover-fill-color: var(--google-gray-50);
-  --secondary-button-text-color: var(--google-gray-700);
-  --small-link-color: var(--google-gray-700);
-  --text-color: var(--google-gray-700);
  background: var(--background-color);
  color: var(--text-color);
  word-wrap: break-word;
}

Also applies to: 26-41

vite/public/chrome-dino-game/index.html (3)

19-27: Google Analytics may silently fail offline
You’re loading gtag.js unconditionally on an offline page. In a true offline context, this external request will never succeed and may trigger console errors. Consider wrapping the GA snippet in an if (navigator.onLine) block or lazy loading it only when connectivity is detected.

---

29-29: Move inline font-size into external CSS
The style="font-size: 75%" on the <body> would be cleaner and more maintainable if moved into style.css.

-<body id="t" class="neterror" style="font-size: 75%">
+<body id="t" class="neterror">

and in style.css:

body.neterror {
  font-size: 75%;
}

---

64-70: Extract duplicated audio data URIs into external assets
You’ve embedded large base64 audio blobs directly in this HTML. This bloats the page and duplicates the same audio in every variant. Consider moving these into separate .mp3 files and referencing them via <audio src="...">.

vite/public/chrome-dino-game/style.css (1)

146-156: Remove or consolidate unused selectors
Selectors like .suggested-left > #control-buttons and .snackbar aren’t present in any of the new Dino pages. These rules add weight to the stylesheet and can be removed or moved into a narrower context if you plan to reuse them elsewhere.

vite/public/chrome-dino-game/4_swimming.html (1)

73-94: Theme switching implementation could be improved.

While the theme switching works, it requires a page reload. Consider using the History API to update the URL without a full page reload, or implementing the theme switching without navigation for a smoother experience.

function changeTheme() {
    const theme = document.getElementById("themeDino").value;
    
-   switch (theme) {
-       case "default":
-           location.href = "index.html";
-           break;
-       case "hurdling":
-           location.href = "1_hurdling.html";
-           break;
-       // other cases...
-   }
+   if (theme) {
+       // Update URL without reload (preserves game state)
+       const newUrl = theme === "default" ? "index.html" : `${theme}.html`;
+       history.pushState({}, "", newUrl);
+       
+       // Load new sprite resources
+       loadThemeResources(theme);
+   }
}

// This would need to be implemented to load the new theme resources
function loadThemeResources(theme) {
    // Load new sprite images, etc.
}

vite/public/chrome-dino-game/1_hurdling.html (2)

61-71: Duplicate code across game variants.

The touch detection code is duplicated across multiple HTML files. Consider moving this logic to a shared JavaScript file to improve maintainability.

- <script>
-     function is_touch_enabled() {
-         return ( 'ontouchstart' in window ) || 
-                ( navigator.maxTouchPoints > 0 ) ||
-                ( navigator.msMaxTouchPoints > 0 );
-     }
-     if ( is_touch_enabled() ) {
-         var box = document.getElementById("heading.msg");
-         box.innerHTML = "Touch the dino to play";
-     }
- </script>
+ <script src="scripts/touch-detection.js"></script>

This would require creating a new touch-detection.js file with the shared logic.

---

73-94: Theme switching logic duplication.

The theme switching function is duplicated across game variants. This should be moved to a shared JavaScript file to reduce redundancy and make maintenance easier.

- <script>
-     function changeTheme() {
-         switch (document.getElementById("themeDino").value) {
-             case "default":
-                 location.href = "index.html";
-                 break;
-             // other cases...
-         }
-     }
- </script>
+ <script src="scripts/theme-switcher.js"></script>

vite/public/chrome-dino-game/styles/neterror.css (1)

1-430: Consider using CSS variables for improved maintainability.

The stylesheet uses hardcoded color values in many places. Refactoring to use CSS custom properties (variables) would improve maintainability and theme consistency.

Consider defining a set of variables at the top of your file:

* {
  font-family: system-ui, 'Segoe UI', Tahoma, sans-serif;
}

+:root {
+  --color-background: #fff;
+  --color-text: #000;
+  --color-blue: var(--google-blue-300, #8ab4f8);
+  --color-gray: var(--google-gray-50, #f8f9fa);
+  --color-dark-gray: rgb(189,193,198);
+  /* Add more variables as needed */
+}

Then use these variables throughout the stylesheet instead of hardcoded values.

vite/public/chrome-dino-game/scripts/offline-sprite-definitions.js (3)

5-6: Consider using a proper enum for game types.

The game types are defined as string literals in an array. Using a proper enum or object with named constants would improve code readability and type safety.

/* @const */
-const GAME_TYPE = ['type_1', 'type_2', 'type_3', 'type_4', 'type_5'];
+const GAME_TYPE = {
+  HURDLING: 'type_1',
+  GYMNASTICS: 'type_2',
+  SURFING: 'type_3',
+  SWIMMING: 'type_4',
+  EQUESTRIAN: 'type_5'
+};

---

26-26: Use const for type definition instead of let.

Type definitions should typically be declared with const rather than let since they're not meant to be reassigned.

-let ObstacleType;
+const ObstacleType = {};  // Or just use JSDoc without variable declaration

---

31-687: Consider extracting common numeric values into named constants.

Several numeric values are repeated throughout the code (like collision box parameters, animation frame rates, etc.). Extracting these into named constants would improve readability and maintainability.

For example, you could define constants for common speeds, gaps, and physics parameters:

const DEFAULT_MIN_GAP = 120;
const DEFAULT_MULTIPLE_SPEED = 4;
const DEFAULT_GRAVITY = 0.6;
const LOWERED_GRAVITY = 0.36;

Then use these constants throughout your sprite definitions where appropriate.

electron/modules/output.ts (1)

12-13: Add trailing comma for consistency.
All entries in the DEBUG_AREAS object use trailing commas except ICONS. Adding a comma maintains uniform formatting.

Apply this diff:

 const DEBUG_AREAS = {
   SPACES: false, // @/sessions/spaces.ts
-  ICONS: false // @/modules/icons.ts
+  ICONS: false, // @/modules/icons.ts
 } as const;

vite/index.html (1)

6-6: Ensure a <title> tag is present for accessibility.
The document currently lacks a <title>, which is important for usability and SEO. Consider adding a descriptive title before the icon link.

Example:

<title>Flow Browser</title>
<link rel="icon" type="image/x-icon" href="/assets/favicon.ico" />

docs/references/tabs.md (1)

1-5: Add a top-level header and clarify mode descriptions.
Starting with a secondary header can be confusing. Introduce a primary title (e.g., # Tabs Reference) and expand each mode’s description for clarity.

Suggested structure:

# Tabs Reference

## Active Tab Modes

- **Standard**: Single tab layout.
- **Glance**: Two-tab glance mode (front & back).
- **Split**: Split-screen tabs side by side.

vite/eslint.config.js (1)

22-26: Disabling react-refresh linting rule

Changed the react-refresh/only-export-components rule from "warn" to "off", while maintaining the allowConstantExport option. This change likely accommodates the component structure in the refactored codebase that may not strictly adhere to the React Refresh optimization requirements.

Consider documenting the reason for disabling this rule, as it might impact hot reloading performance in some cases.

electron/browser/tabs/tab-groups/split.ts (1)

1-7: Approved, but note pending implementation.

This is a good starting structure for SplitTabGroup with proper inheritance from BaseTabGroup. The TODO comment correctly indicates that implementation for split layout is still pending.

Consider adding a JSDoc comment to describe what the split tab group will do when implemented:

import { BaseTabGroup } from "@/browser/tabs/tab-groups";

+/**
+ * Tab group implementation for split view layouts.
+ * Allows displaying multiple tabs side by side in a single window.
+ */
export class SplitTabGroup extends BaseTabGroup {
  public mode: "split" = "split";

  // TODO: Implement split tab group layout
}

electron/ipc/app/app.ts (1)

1-9: LGTM - Good implementation of app info handler.

The implementation correctly uses ipcMain.handle with async/await for the IPC handler. The properties being returned are appropriate for basic app information.

Consider adding a TypeScript interface for the returned data structure:

import { app } from "electron";
import { ipcMain } from "electron";

+interface AppInfo {
+  version: string;
+  packaged: boolean;
+}

ipcMain.handle("app:get-info", async () => {
  return {
    version: app.getVersion(),
    packaged: app.isPackaged
  } as AppInfo;
});

docs/contributing/hot-reloading.md (1)

1-40: Good documentation, could be enhanced with additional details.

This is a clear and concise guide for setting up hot reloading. The prerequisites, steps, and troubleshooting sections provide a good foundation for developers.

Consider enhancing the documentation with additional details:

1. What types of changes trigger hot reloading vs. requiring a full restart?
2. How can developers verify hot reloading is working correctly?
3. Which parts of the application support hot reloading (renderer process only, or main process too)?
4. Are there any limitations or known issues with hot reloading?

For example, you could add a section like:

## What to Expect

Hot reloading will automatically refresh the UI when you make changes to:
- React components in `src/renderer`
- CSS/SCSS files
- ...

Changes to the following will require a full restart:
- Electron main process files
- IPC handlers
- ...

You'll know hot reloading is working when you see "HMR update successful" in the browser console.

electron/saving/datastore.ts (1)

35-35: Changed visibility from private to public

The directoryPath property has been changed from private to public. This exposes an implementation detail that was previously encapsulated. Consider if this change is necessary or if it could be kept private with a getter method instead.

-  public directoryPath: string;
+  private directoryPath: string;
+
+  /**
+   * Gets the directory path for this datastore
+   * @returns The path to the directory containing this datastore
+   */
+  getDirectoryPath(): string {
+    return this.directoryPath;
+  }

electron/browser/utility/menu/items/app.ts (1)

7-22: Consider platform-specific menu customization

The menu includes macOS-specific roles like services and hideOthers that may not be applicable on other platforms. Consider making the menu structure adapt to the current platform.

export const createAppMenu = (): MenuItemConstructorOptions => ({
  role: "appMenu",
  submenu: [
    { role: "about" },
    { type: "separator" },
    {
      label: "Settings",
      click: () => {
        settings.show();
      }
    },
+   ...(process.platform === 'darwin' ? [
    { role: "services" },
    { type: "separator" },
    { role: "hide" },
    { role: "hideOthers" },
    { role: "showAllTabs" },
+   ] : []),
    { type: "separator" },
    { role: "quit" }
  ]
});

docs/references/omnibox-scores.md (1)

5-12: Consider using en dashes for numerical ranges

For better typographical correctness, use en dashes (–) instead of hyphens (-) when indicating numerical ranges. This improves readability and follows proper typographical conventions.

-**~1100 - 1500:** Open Tab (Switch) - _Encourages switching to existing tabs. Score scales with title/URL similarity._
+**~1100 – 1500:** Open Tab (Switch) - _Encourages switching to existing tabs. Score scales with title/URL similarity._
-**1400 - 1450+:** History URL (Exact Match) - _Very high score for exact URL matches in history._
+**1400 – 1450+:** History URL (Exact Match) - _Very high score for exact URL matches in history._
-**1100 - 1200:** Pedal - _Browser actions triggered by keywords (e.g., "settings"). Score scales with trigger similarity._
+**1100 – 1200:** Pedal - _Browser actions triggered by keywords (e.g., "settings"). Score scales with trigger similarity._
-**~900 - 1450:** History URL (Similarity/Prefix Match) - _Score based on URL/title similarity, visit/typed counts, and prefix matching._
+**~900 – 1450:** History URL (Similarity/Prefix Match) - _Score based on URL/title similarity, visit/typed counts, and prefix matching._
-**~600 - 1000:** Search Suggestion - _Fetched suggestions, ranked by provider order and similarity to input._
+**~600 – 1000:** Search Suggestion - _Fetched suggestions, ranked by provider order and similarity to input._
-**350 - 800:** Zero Suggest (Recent Tabs) - _Suggestions shown before typing, ranked by tab recency._
+**350 – 800:** Zero Suggest (Recent Tabs) - _Suggestions shown before typing, ranked by tab recency._
-**500 - 700:** Zero Suggest (Most Visited History) - _Suggestions shown before typing, ranked by visit count._
+**500 – 700:** Zero Suggest (Most Visited History) - _Suggestions shown before typing, ranked by visit count._

🧰 Tools

🪛 LanguageTool

[typographical] ~5-~5: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...igher in the suggestion list. - ~1100 - 1500: Open Tab (Switch) - _Encourages ...

(DASH_RULE)

---

[typographical] ~6-~6: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...les with title/URL similarity._ - 1400 - 1450+: History URL (Exact Match) - _Ve...

(DASH_RULE)

---

[typographical] ~8-~8: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...ch for..." or typed URL entry._ - 1100 - 1200: Pedal - _Browser actions trigger...

(DASH_RULE)

---

[typographical] ~9-~9: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...cales with trigger similarity._ - ~900 - 1450: History URL (Similarity/Prefix M...

(DASH_RULE)

---

[typographical] ~10-~10: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...d counts, and prefix matching._ - ~600 - 1000: Search Suggestion - _Fetched sug...

(DASH_RULE)

---

[typographical] ~11-~11: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ... order and similarity to input._ - 350 - 800: Zero Suggest (Recent Tabs) - _Sug...

(DASH_RULE)

---

[typographical] ~12-~12: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ... typing, ranked by tab recency._ - 500 - 700: Zero Suggest (Most Visited Histor...

(DASH_RULE)

electron/ipc/main.ts (1)

1-21: Missing documentation for side-effect nature of imports

The file relies on side-effect imports (modules are executed and register handlers upon import), but doesn't document this intention explicitly. This might confuse developers who expect to see handler registrations in this file.

+ // This file serves as the central import point for all IPC handlers.
+ // Each imported module self-registers its IPC handlers when imported.
 // Browser APIs
 import "@/ipc/browser/browser";
 import "@/ipc/browser/tabs";

vite/public/edge-surf-game-v1/resources/js/base-error-reporting.js (1)

4-17: Consider namespacing to avoid global pollution

The function is defined in the global scope, which could lead to namespace conflicts in a complex web application environment.

-function hookErrorReporting(component) {
+// Namespace the function to avoid global pollution
+window.FlowBrowser = window.FlowBrowser || {};
+window.FlowBrowser.hookErrorReporting = function(component) {
   window.onerror = (message, source, lineno, columnNumber, error) => {
     const errorInfo = {
       column: columnNumber,
       component,
       line: lineno,
       message: error.message,
       name: error.name,
       source_url: source,
       stack: error.stack
     };
     chrome.errorReporting.reportError(errorInfo);
   };
 }

electron/browser/utility/menu/items/file.ts (1)

19-19: Consider removing unnecessary return statement

The return keyword before openNewTab(tabbedBrowserWindow) is unnecessary in a click handler since the return value isn't used by the Electron menu system.

-        return openNewTab(tabbedBrowserWindow);
+        openNewTab(tabbedBrowserWindow);

electron/browser/components/glance-modal.ts (2)

14-15: Consider extracting the hardcoded URL to a constant

The hardcoded URL "flow-internal://glance-modal/" should be extracted to a constant for better maintainability.

+const GLANCE_MODAL_URL = "flow-internal://glance-modal/";
+
 export class GlanceModal {
   public readonly view: WebContentsView;

   constructor() {
     const view = new WebContentsView({
       webPreferences: {
         transparent: true
       }
     });
     view.setBorderRadius(8);

     const webContents = view.webContents;
-    webContents.loadURL("flow-internal://glance-modal/");
+    webContents.loadURL(GLANCE_MODAL_URL);

---

29-31: Consider adding error handling in destroy method

The destroy method should handle potential errors when closing web contents.

 public destroy() {
-    this.view.webContents.close();
+    try {
+      this.view.webContents.close();
+    } catch (error) {
+      console.error('Error closing GlanceModal web contents:', error);
+    }
 }

electron/browser/utility/views.ts (1)

8-30: Add utility methods to enhance the ViewsManager functionality

Consider adding utility methods to improve the class's functionality, such as getting views by ID and cleaning up all views.

 export class ViewsManager {
   private window: BrowserWindow;
   private contentView: View;
   private views: Map<number, ViewData>;

   constructor(window: BrowserWindow) {
     this.window = window;
     this.contentView = window.contentView;
     this.views = new Map();
   }

   // ... existing methods ...

+  public has(view: WebContentsView): boolean {
+    return this.views.has(view.webContents.id);
+  }
+
+  public getViewById(id: number): View | undefined {
+    return this.views.get(id)?.view;
+  }
+
+  public clear() {
+    for (const [id, viewData] of this.views.entries()) {
+      this.contentView.removeChildView(viewData.view);
+      this.views.delete(id);
+    }
+  }
 }

electron/ipc/session/profiles.ts (1)

14-17: Remove debug logging before production deployment

The console.log statement should be removed as it's unnecessary in production code and may expose sensitive profile information in logs.

ipcMain.handle("profiles:update", async (event, profileId: string, profileData: Partial<ProfileData>) => {
-  console.log("Updating profile:", profileId, profileData);
  return await updateProfile(profileId, profileData);
});

electron/browser/utility/menu/items/archive.ts (2)

5-7: Consider renaming "Archive" menu to improve user understanding

The comment about renaming "Archive" to "History" or "Navigation" is valid. "Archive" is not a standard term for backward/forward navigation in browsers and may confuse users. "History" or "Navigation" would be more intuitive.

export const createArchiveMenu = (browser: Browser): MenuItemConstructorOptions => ({
-  label: "Archive", // Consider renaming to "History" or "Navigation" if more appropriate
+  label: "Navigation",
  submenu: [

---

5-33: Consider adding more navigation options to enhance menu functionality

The current implementation only covers basic forward/backward navigation. Consider enhancing this menu with additional navigation features like:

• Home page navigation
• Reload page
• View history
• Access to bookmarks

These would make the menu more useful and align better with standard browser navigation menus.

export const createArchiveMenu = (browser: Browser): MenuItemConstructorOptions => ({
  label: "Archive", // Consider renaming to "History" or "Navigation" if more appropriate
  submenu: [
    {
      label: "Go Back",
      accelerator: "CmdOrCtrl+Left",
      click: () => {
        const tabWc = getTabWcFromFocusedWindow(browser);
        if (!tabWc) return;
        // Check if back navigation is possible before calling goBack
        if (tabWc.canGoBack()) {
          tabWc.goBack();
        }
      }
    },
    {
      label: "Go Forward",
      accelerator: "CmdOrCtrl+Right",
      click: () => {
        const tabWc = getTabWcFromFocusedWindow(browser);
        if (!tabWc) return;
        // Check if forward navigation is possible before calling goForward
        if (tabWc.canGoForward()) {
          tabWc.goForward();
        }
      }
    },
+    { type: 'separator' },
+    {
+      label: "Reload",
+      accelerator: "CmdOrCtrl+R",
+      click: () => {
+        const tabWc = getTabWcFromFocusedWindow(browser);
+        if (!tabWc) return;
+        tabWc.reload();
+      }
+    },
+    {
+      label: "Home",
+      accelerator: "Alt+Home",
+      click: () => {
+        // Implementation for navigating to home page
+      }
+    }
  ]
});

electron/browser/utility/menu/items/edit.ts (1)

13-29: Well-implemented "Copy URL" feature

The "Copy URL" functionality is well-implemented with:

• Proper keyboard shortcut (CmdOrCtrl+Shift+C)
• Appropriate safety checks for window data and web contents
• Clear clipboard operation

Consider implementing the TODO to show a notification to the user when the URL is copied. This would provide better feedback and improve user experience.

clipboard.writeText(url);
// TODO: Show notification to user that the URL has been copied
+ // Simple temporary solution:
+ tabWc.executeJavaScript(`
+   if (!window.flowNotificationTimeout) {
+     const notification = document.createElement('div');
+     notification.textContent = 'URL copied to clipboard';
+     notification.style.cssText = 'position:fixed;bottom:20px;left:50%;transform:translateX(-50%);background:#333;color:#fff;padding:8px 16px;border-radius:4px;z-index:9999;';
+     document.body.appendChild(notification);
+     window.flowNotificationTimeout = setTimeout(() => {
+       notification.remove();
+       delete window.flowNotificationTimeout;
+     }, 2000);
+   }
+ `);

electron/browser/utility/menu/items/view.ts (3)

29-32: Improve error handling for tab reload

Add error handling around the reload operation to ensure failures are properly logged and handled.

click: () => {
  const tabWc = getTabWcFromFocusedWindow(browser);
  if (!tabWc) return;
-  tabWc.reload();
+  try {
+    tabWc.reload();
+  } catch (error) {
+    console.error("Failed to reload tab:", error);
+  }
}

---

47-70: Simplify complex conditional logic for closing tab

The tab closing logic has multiple nested conditions which make it harder to read and maintain. Consider refactoring to improve readability.

click: () => {
  const winData = getFocusedWindowData();
  if (!winData) return;

  if (winData.type !== WindowType.BROWSER) {
    if (winData.window.closable) {
      winData.window.close();
    }
    return;
  }

  const browserWindow = winData.window;
-  if (browserWindow && isOmniboxOpen(browserWindow)) {
-    hideOmnibox(browserWindow);
-  } else {
-    const tab = getTab(browser, winData);
-    if (tab) {
-      tab.destroy();
-    } else {
-      if (winData.window) {
-        winData.window.close();
-      }
-    }
-  }
+  // Handle omnibox if it's open
+  if (browserWindow && isOmniboxOpen(browserWindow)) {
+    hideOmnibox(browserWindow);
+    return;
+  }
+  
+  // Try to close tab if it exists
+  const tab = getTab(browser, winData);
+  if (tab) {
+    tab.destroy();
+    return;
+  }
+  
+  // Fall back to closing the window
+  if (winData.window) {
+    winData.window.close();
+  }
}

---

76-79: Add error handling for developer tools toggle

Similar to the reload operation, add error handling around the toggleDevTools call.

click: () => {
  const tabWc = getTabWcFromFocusedWindow(browser);
  if (!tabWc) return;
-  tabWc.toggleDevTools();
+  try {
+    tabWc.toggleDevTools();
+  } catch (error) {
+    console.error("Failed to toggle developer tools:", error);
+  }
}

electron/ipc/app/new-tab.ts (1)

45-51: Strengthen error handling in IPC listener

The IPC listener doesn't have comprehensive error handling around the openNewTab operation.

-ipcMain.on("new-tab:open", (event) => {
-  const webContents = event.sender;
-  const win = browser?.getWindowFromWebContents(webContents);
-  if (!win) return;
-
-  return openNewTab(win);
-});
+ipcMain.on("new-tab:open", (event) => {
+  try {
+    const webContents = event.sender;
+    if (!browser) {
+      console.error("Browser is not initialized");
+      return;
+    }
+    
+    const win = browser.getWindowFromWebContents(webContents);
+    if (!win) {
+      console.error("Could not find window for web contents");
+      return;
+    }
+
+    openNewTab(win);
+  } catch (error) {
+    console.error("Error opening new tab:", error);
+  }
+});

electron/ipc/browser/page.ts (1)

15-21: Consider using ipcMain.handle for proper response handling

The current implementation uses ipcMain.on but returns null when a window isn't found. Since this return value isn't sent back to the renderer when using ipcMain.on, consider using ipcMain.handle instead for proper response handling.

-ipcMain.on("page:set-bounds", async (event, bounds: PageBounds) => {
+ipcMain.handle("page:set-bounds", async (event, bounds: PageBounds) => {
  const webContents = event.sender;
  const window = browser?.getWindowFromWebContents(webContents);
  if (!window) return null;

  window.setPageBounds(bounds);
+  return true;
});

electron/ipc/browser/navigation.ts (2)

4-17: Return value not sent to renderer

The handler returns boolean values but uses ipcMain.on instead of ipcMain.handle, meaning these return values aren't sent back to the renderer. If the renderer needs to know whether the navigation succeeded, consider using ipcMain.handle instead.

-ipcMain.on("navigation:go-to", (event, url: string, tabId?: number) => {
+ipcMain.handle("navigation:go-to", async (event, url: string, tabId?: number) => {
  const webContents = event.sender;
  const window = browser?.getWindowFromWebContents(webContents);
  if (!window) return false;

  const currentSpace = window.getCurrentSpace();
  if (!currentSpace) return false;

  const tab = tabId ? browser?.getTabFromId(tabId) : browser?.tabs.getFocusedTab(window.id, currentSpace);
  if (!tab) return false;

  tab.loadURL(url);
  return true;
});

---

49-54: Unused return value

The return value from tab.webContents?.navigationHistory?.goToIndex(index) isn't being used since this is an ipcMain.on handler, not a handle. Consider either removing the return statement or using ipcMain.handle if the renderer needs the result.

-ipcMain.on("navigation:go-to-entry", (event, tabId: number, index: number) => {
+ipcMain.on("navigation:go-to-entry", (event, tabId: number, index: number) => {
  const tab = browser?.getTabFromId(tabId);
  if (!tab) return;

-  return tab.webContents?.navigationHistory?.goToIndex(index);
+  tab.webContents?.navigationHistory?.goToIndex(index);
});

electron/onboarding/main.ts (1)

36-41: Return type can be tightened & Promise leakage avoided
createOnboardingWindow() currently returns Promise<any>. Give callers a concrete contract and avoid an edge‑case where ready-to-show fires before the listener is attached:

-function createOnboardingWindow() {
+function createOnboardingWindow(): Promise<BrowserWindow> {
   ...
-  return new Promise((resolve) => {
-    window.once("ready-to-show", () => {
-      resolve(window);
-    });
-  });
+  return new Promise<BrowserWindow>((resolve) => {
+    if (window.isReadyToShow()) {
+      resolve(window);
+    } else {
+      window.once("ready-to-show", () => resolve(window));
+    }
+  });
 }

electron/saving/open-external.ts (2)

5-16: Key derivation ignores path & query – risk of over‑broad permissions
getKey() collapses the whole requesting URL to only protocol//host.
Example: allowing https://evil.example.com will also whitelist https://evil.example.com/suspicious?download=exe.
If the intention is to scope by origin and path you should include url.pathname (and maybe .port separately) when constructing the key.

-  const minifiedUrl = `${url.protocol}//${url.host}`;
+  // Include pathname to avoid over‑broad matches
+  const minifiedUrl = `${url.protocol}//${url.host}${url.pathname}`;

[security]

---

34-50: Unsafe cast to boolean & silent error swallowing
filter(Boolean) coerces every object to true; you rely on preceding return null to drop invalid entries but any accidental non‑object truthy value (e.g., string "true") leaks through.
Also the catch block discards decoding errors – consider logging for diagnosis.

-    .filter(Boolean);
+    .filter((v): v is {requestingURL:string;openingProtocol:string} => v !== null);

electron/index.ts (2)

104-110: Suspicious double‑window access – probably a typo
window.window.focus() suggests window is an object wrapping BrowserWindow.
If so, prefer exposing a focus() helper or property to avoid leaking internal structure & to future‑proof refactors:

-        window.window.focus();
+        window.focus();

---

138-144: Duplicate async call – small perf optimisation
hasCompletedOnboarding() is executed once at startup and again on window-all-closed.
Cache its resolved value (or listen for onboarding‑completed event) to avoid touching disk twice.

docs/api/browser.md (1)

19-19: Minor grammatical issue in constructor description.

The sentence structure suggests "Automatically creates" should be "It automatically creates" to maintain subject-verb agreement.

-Creates a new Browser instance and initializes the window and profile managers. Automatically creates the initial window after initialization.
+Creates a new Browser instance and initializes the window and profile managers. It automatically creates the initial window after initialization.

🧰 Tools

🪛 LanguageTool

[grammar] ~19-~19: Possible subject-verb agreement error.
Context: ...instance and initializes the window and profile managers. Automatically creates the ini...

(IS_AND_ARE)

electron/ipc/session/spaces.ts (1)

18-61: Add error handling to IPC handlers.

The current IPC handlers directly pass through to the underlying functions without explicit error handling. While the underlying functions may handle errors internally, adding try-catch blocks would ensure IPC communication remains robust even if unexpected errors occur.

Here's an example pattern to apply:

ipcMain.handle("spaces:get-all", async (event) => {
+  try {
    return await getSpaces();
+  } catch (error) {
+    console.error("Error in spaces:get-all handler:", error);
+    return [];
+  }
});

This pattern could be applied to all handlers based on their expected return values.

vite/public/edge-surf-game-v1/resources/js/assert.js (1)

85-85: Unexpected console warning about non-JS module files.

This warning message references a Chrome bug ID and appears to be unrelated to this JavaScript module. It might be a leftover from another context or code migration.

Consider removing this warning if it's not applicable to this file, or adding a comment explaining its relevance if it's intentionally included.

electron/browser/utility/hot-reload.ts (2)

14-33: Development server detection with state caching.

The implementation checks if the development server is running and caches the result, which is efficient. However, the error handling could be improved.

Consider logging the error details to help with debugging:

    .catch((error) => {
      isDevServerRunning = false;
+     if (!app.isPackaged) {
+       console.debug('Development server not running:', error.message);
+     }
      return false;
    });

---

63-77: Busy-wait approach for request throttling.

The current implementation uses a busy-wait approach with randomized timeouts to manage concurrency. While it works, it could be more efficient.

Consider using a queue-based approach or a semaphore pattern for more efficient request throttling:

- while (amountOfRequests >= MAX_REQUESTS) {
-   await new Promise((resolve) => setTimeout(resolve, getRandomTimeout()));
- }
- 
- amountOfRequests++;
+ const semaphore = {
+   acquire: async () => {
+     while (amountOfRequests >= MAX_REQUESTS) {
+       await new Promise(resolve => setTimeout(resolve, getRandomTimeout()));
+     }
+     amountOfRequests++;
+   },
+   release: () => {
+     amountOfRequests--;
+   }
+ };
+ 
+ await semaphore.acquire();

And later:

- setTimeout(() => {
-   amountOfRequests--;
- }, getRandomTimeout());
+ setTimeout(() => {
+   semaphore.release();
+ }, getRandomTimeout());

electron/browser/utility/menu/helpers.ts (3)

1-4: Good imports, but unused dependency.

The file imports the necessary modules, but getSpace from @/sessions/spaces is imported but never used in this file.

Remove the unused import:

-import { getSpace } from "@/sessions/spaces";

---

6-10: Redundant wrapper function for getFocusedWindow.

The getFocusedWindowData function doesn't add significant value over the directly imported getFocusedWindow function.

Consider adding more functionality to justify this wrapper or use the imported function directly where needed.

---

12-21: Missing TypeScript return type annotations.

The function lacks explicit return type annotations, which would improve type safety and documentation.

Add explicit return types:

-export const getFocusedBrowserWindowData = () => {
+export const getFocusedBrowserWindowData = (): WindowData | null => {

electron/modules/icons.ts (3)

1-1: Remove unused ipcMain import
ipcMain is no longer referenced after the IPC handlers were moved to a dedicated module, so this import is now dead code. Eliminating it avoids potential linter warnings and keeps the dependency list tidy.

-import { app, ipcMain, NativeImage, nativeImage } from "electron";
+import { app, NativeImage, nativeImage } from "electron";

---

73-83: Avoid synchronous file I/O during icon transformation
fs.readFileSync blocks the main thread during start‑up and every icon change. Switching to fs.promises.readFile (or await fs.promises.readFile) keeps the event loop responsive, which matters on slower disks or when the image is large.

-    const inputBuffer = fs.readFileSync(imagePath);
+    const inputBuffer = await fs.promises.readFile(imagePath);

Also applies to: 110-113

---

175-182: Defer initial icon work until after app.whenReady()
setAppIcon("default") performs an expensive Sharp transform and may try to set the dock icon before Electron is ready. Wrapping it in app.whenReady() prevents unnecessary early processing and eliminates the (small) risk of calling macOS‑only APIs too early.

-setAppIcon("default").catch((error) => {
-  debugError("ICONS", "Failed initial setAppIcon call:", error);
-});
+app.whenReady().then(() =>
+  setAppIcon("default").catch((error) => {
+    debugError("ICONS", "Failed initial setAppIcon call:", error);
+  })
+);

electron/ipc/browser/tabs.ts (1)

48-55: Remove dead windowProfiles accumulation
windowProfiles is populated but never consumed. Keeping unused variables around increases cognitive load and may trigger linter warnings.

-  const windowProfiles: string[] = [];
-  const windowSpaces: string[] = [];
+  const windowSpaces: string[] = [];

electron/browser/utility/menu/items/spaces.ts (2)

1-5: Remove opinionated comments from production code
Lines 1‑4 carry a personal rant about Lucide’s naming scheme. Such comments can feel unprofessional and clutter the codebase. Recommend deleting or moving to a GitHub discussion.

---

114-118: browser parameter is currently unused
createSpacesMenu receives a Browser instance but never touches it. Either use it (e.g., for window retrieval) or drop the parameter to avoid misleading signatures.

electron/browser/window-manager.ts (3)

34-48: Simplify error handling in createWindow

The try/catch block in createWindow just rethrows the error without adding any value. This creates unnecessary code complexity.

  public createWindow(
    browser: Browser,
    type: BrowserWindowType = "normal",
    options: BrowserWindowCreationOptions = {}
  ): TabbedBrowserWindow {
-   try {
-     const window = new TabbedBrowserWindow(browser, type, options);
-     this.windows.set(window.id, window);
-
-     window.on("destroy", () => {
-       this.windows.delete(window.id);
-       this.eventEmitter.emit("window-destroyed", window);
-     });
-
-     this.eventEmitter.emit("window-created", window);
-     return window;
-   } catch (error) {
-     throw error;
-   }
+   const window = new TabbedBrowserWindow(browser, type, options);
+   this.windows.set(window.id, window);
+
+   window.on("destroy", () => {
+     this.windows.delete(window.id);
+     this.eventEmitter.emit("window-destroyed", window);
+   });
+
+   this.eventEmitter.emit("window-created", window);
+   return window;
  }

🧰 Tools

🪛 Biome (1.9.4)

[error] 46-46: The catch clause that only rethrows the original error is useless.

An unnecessary catch clause can be confusing.
Unsafe fix: Remove the try/catch clause.

(lint/complexity/noUselessCatch)

---

67-83: Add null check and early return to getWindowFromWebContents method

The method should validate if webContents is null or undefined before attempting to use it to prevent potential runtime errors.

  public getWindowFromWebContents(webContents: WebContents): TabbedBrowserWindow | null {
+   if (!webContents) {
+     return null;
+   }
+   
    for (const window of this.windows.values()) {
      for (const windowWebContents of window.coreWebContents) {
        if (webContents.id === windowWebContents.id) {
          return window;
        }
      }

      // Temporary solution for tabs in the window
      for (const windowWebContents of window.window.contentView.children) {
        if (windowWebContents instanceof WebContentsView && webContents.id === windowWebContents.webContents.id) {
          return window;
        }
      }
    }
    return null;
  }

---

17-24: Consider adding event documentation

The class emits events via the eventEmitter but doesn't document what events are available and their payload types.

Add JSDoc comments that describe what events the WindowManager emits through the BrowserEvents interface, such as "window-created" and "window-destroyed".

electron/browser/view-manager.ts (2)

36-38: Add hasView method to check if a view is managed

The class currently doesn't provide a way to check if a view is being managed without retrieving its z-index.

  getViewZIndex(view: View): number | undefined {
    return this.views.get(view);
  }
+
+ hasView(view: View): boolean {
+   return this.views.has(view);
+ }

---

57-81: Optimize and improve error handling in reorderViews method

The current implementation adds all views back to the parent, which might be inefficient. It also doesn't check if a view is already in the parent before adding it.

  private reorderViews(): void {
    // Sort views by zIndex, lowest first
    const sortedViews = Array.from(this.views.entries()).sort(([, aIndex], [, bIndex]) => aIndex - bIndex);

+   // First remove all views from parent to ensure clean state
+   sortedViews.forEach(([view]) => {
+     try {
+       this.parentView.removeChildView(view);
+     } catch (error) {
+       // View might already be removed or invalid
+       console.warn(`Failed to remove view during reorder preparation:`, error);
+     }
+   });

    // Add views back in order. addChildView brings the added view to the top
    // relative to its siblings managed by this parent.
    // Adding lowest zIndex first means highest zIndex will end up visually on top.
    sortedViews.forEach(([view]) => {
      try {
        // Check if view is still valid (not destroyed, etc.) - View API has no direct 'isDestroyed'
        // Rely on addChildView potentially throwing an error if the view is invalid
        this.parentView.addChildView(view);
      } catch (error) {
        console.error(`Failed to add/reorder view during reorder:`, error);
        // Attempt to find the ID for the failed view to remove it from the map
-       const failedViewEntry = Array.from(this.views.entries()).find(([, zIndex]) => zIndex === zIndex);
+       const failedViewEntry = Array.from(this.views.entries()).find(([v]) => v === view);
        if (failedViewEntry) {
          console.error(`Removing view with ID ${failedViewEntry[0]} from manager due to reorder error.`);
          this.views.delete(failedViewEntry[0]);
        } else {
          console.error(`Could not find ID for the failed view during reorder.`);
        }
      }
    });
  }

🧰 Tools

🪛 Biome (1.9.4)

[error] 72-72: Comparing to itself is potentially pointless.

(lint/suspicious/noSelfCompare)

electron/browser/components/omnibox.ts (3)

18-56: Fix inconsistent variable naming in constructor

The constructor uses "onmiboxView" and "onmiboxWC" instead of "omniboxView" and "omniboxWC", creating a naming inconsistency.

  constructor(parentWindow: BrowserWindow) {
    debugPrint("OMNIBOX", `Creating new omnibox for window ${parentWindow.id}`);
-   const onmiboxView = new WebContentsView({
+   const omniboxView = new WebContentsView({
      webPreferences: {
        transparent: true
      }
    });
-   const onmiboxWC = onmiboxView.webContents;
+   const omniboxWC = omniboxView.webContents;

-   onmiboxView.setBorderRadius(13);
+   omniboxView.setBorderRadius(13);

    // on focus lost, hide omnibox
-   onmiboxWC.on("blur", () => {
+   omniboxWC.on("blur", () => {
      debugPrint("OMNIBOX", "WebContents blur event received");
      this.maybeHide();
    });
    parentWindow.on("resize", () => {
      debugPrint("OMNIBOX", "Parent window resize event received");
      this.updateBounds();
    });

    // on window focus, focus omnibox if showing
    parentWindow.on("focus", () => {
      debugPrint("OMNIBOX", "Parent window focus event received");
      this.refocus();
    });

    setTimeout(() => {
      this.loadInterface(null);
      this.updateBounds();
      this.hide();
    }, 0);

    omniboxes.set(parentWindow, this);

-   this.view = onmiboxView;
-   this.webContents = onmiboxWC;
+   this.view = omniboxView;
+   this.webContents = omniboxWC;
    this.window = parentWindow;
  }

---

163-190: Add consistent checks for destroyed state in maybeHide method

The maybeHide method has inconsistent checks for destroyed windows. It would be more robust to check all cases consistently.

  maybeHide() {
    if (this.window.isDestroyed()) {
      return;
    }

    this.assertNotDestroyed();

    // Keep open if webContents is being inspected
-   if (!this.window.isDestroyed() && this.webContents.isDevToolsOpened()) {
+   if (this.webContents.isDevToolsOpened()) {
      debugPrint("OMNIBOX", "preventing close due to DevTools being open");
      return;
    }

    // The user may need to access a
    // program outside of the app. Closing the popup would then add
    // inconvenience.
    if (browser) {
      const hasFocus = browser.getWindows().some((win) => {
        if (win.window.isDestroyed()) {
          return false;
        }
        return win.window.isFocused();
      });
      if (!hasFocus) {
        debugPrint("OMNIBOX", "preventing close due to focus residing outside of the app");
        return;
      }
    }

    // All conditions passed, hide omnibox
    debugPrint("OMNIBOX", "All conditions passed, hiding omnibox");
    this.hide();
  }

---

68-70: Fix variable name inconsistency in loadInterface method

The loadInterface method uses "onmiboxWC" instead of "omniboxWC", creating a naming inconsistency.

  loadInterface(params: QueryParams | null) {
    this.assertNotDestroyed();

    debugPrint("OMNIBOX", `Loading interface with params: ${JSON.stringify(params)}`);
-   const onmiboxWC = this.webContents;
+   const omniboxWC = this.webContents;

    const url = new URL("flow-internal://omnibox/");

Fix this inconsistency throughout the method:

    const urlString = url.toString();
-   if (onmiboxWC.getURL() !== urlString) {
+   if (omniboxWC.getURL() !== urlString) {
      debugPrint("OMNIBOX", `Loading new URL: ${urlString}`);
-     onmiboxWC.loadURL(urlString);
+     omniboxWC.loadURL(urlString);
    } else {
      debugPrint("OMNIBOX", "Reloading current URL");
-     onmiboxWC.reload();
+     omniboxWC.reload();
    }

vite/public/edge-surf-game-v1/resources/js/parse_html_subset.js (1)

13-25: Guard against missing Trusted‑Types support

toTrustedHtml assumes the global trustedTypes object is always present. If this helper is invoked in a non‑Chromium environment (e.g. Node‑based unit tests) it will throw a ReferenceError.

Consider returning the input unchanged when window.trustedTypes (or trustedTypes) is not available.

electron/saving/settings.ts (1)

14-44: DRY up duplicated caching logic

newTabMode and sidebarCollapseMode follow the exact same read‑cache‑validate‑persist pattern. Extracting a small generic helper would:

• eliminate duplication
• align validation/persistence behaviour automatically for future settings
• make unit‑testing easier

Example shape (pseudo‑code):

async function loadSetting<T>(
  key: string,
  schema: z.ZodType<T>,
  defaultValue: T,
): Promise<T> { … }

Then each setting becomes a one‑liner.

Also applies to: 46-80

electron/modules/favicons.ts (2)

400-410: Docstring no longer matches implementation

The comment above normalizeURL still explains only trailing‑slash / protocol logic, but the function now also strips query, hash and (behind a flag) the path. Update the doc so future maintainers aren’t surprised by cache misses.

---

475-479: Use error codes instead of fragile string matching

Relying on the exact wording "ClientRequest only supports http: and https: protocols" is brittle and locale‑dependent. Prefer checking error.code === 'ERR_INVALID_PROTOCOL' (or similar) if Electron exposes one.

electron/browser/utility/protocols.ts (2)

80-89: Avoid per‑request dev‑server pings

isDevelopmentServerRunning() is called on every asset request when
hot‑reload is enabled. In dev mode a single page load can easily
generate hundreds of requests, turning the ping into a bottleneck.

Cache the result for a short interval or compute it once at startup
to shave noticeable latency off the development experience.
[performance]

---

170-200: Double‑check asset path normalisation

Good job using path.normalize() and a prefix check!
One tiny nit: prepend assetsDir + path.sep (like in the previous
comment) so that a sibling path such as
${assetsDir}-evil cannot pass the startsWith test.

electron/browser/tabs/tab-bounds.ts (3)

5-6: Remove dead constant

USE_IMMEDIATE is declared but never used after the rewrite.

-const USE_IMMEDIATE = false;

Deleting unused code avoids reader confusion and keeps bundle size
tight.

---

78-96: Prefer setInterval or requestAnimationFrame for steady frame loops

Manually chaining setTimeout introduces drift because each callback
fires after execution time plus the requested delay.
Using setInterval (or requestAnimationFrame when a view is attached
to a BrowserWindow) keeps spacing more uniform and simplifies
cancellation:

-this.animationFrameId = setTimeout(loop, MS_PER_FRAME);
+this.animationFrameId = setInterval(loop, MS_PER_FRAME);

Remember to clearInterval in stopAnimationLoop().
[performance]

---

210-239: Potential instability from explicit Euler integration

The spring system advances position with:

this.bounds[dim] += velocity * dt
velocity += acceleration * dt

Explicit Euler can overshoot or oscillate at high stiffness /
framerates. A semi‑implicit (symplectic) step is nearly free and far
more stable:

this.velocity[dim] += acceleration * deltaTime;
this.bounds[dim] += this.velocity[dim] * deltaTime;

(Swap the two lines.)

Not urgent, but worth considering if you observe jitter in large window
moves.

vite/public/edge-surf-game-v1/resources/js/load_time_data.js (1)

213-216: Suppress Biome false‑positive or hard‑code the allowed typeof values

Biome warns that typeof … === type uses a non‑literal on line 215.
This is intentional here, but you can silence or fix the rule:

Option A – inline ignore

// biome-ignore lint/suspicious/useValidTypeof
expect(typeof value === type, …);

Option B – validate against the canonical set of typeof strings before
comparison.

🧰 Tools

🪛 Biome (1.9.4)

[error] 215-215: Invalid typeof comparison value: this expression is not a string literal

not a string literal

(lint/suspicious/useValidTypeof)

docs/api/tabs/tab.md (3)

51-65: Clarify view and webContents typings

The docs list view as PatchedWebContentsView but the class name is never introduced in the public API section (nor elsewhere in the repo, judging from the context).
• If PatchedWebContentsView is an internal alias, expose/define it up‑front or remove the “Patched” prefix in public docs so consumers know they can safely rely on the vanilla Electron WebContentsView.
• Likewise, the relationship between view and webContents could use a short sentence explaining that webContents is available via view.webContents, to avoid newcomers accidentally manipulating them out of sync.

🧰 Tools

🪛 LanguageTool

[style] ~53-~53: To form a complete sentence, be sure to include a subject.
Context: ...d: (string) The associated space ID. Can be updated. - visible: (boolean`) Wh...

(MISSING_IT_THERE)

---

68-77: Bullet list ⇒ definition list for readability

The “Key Methods” section repeats the pattern
- method(): description
which renders as a plain bullet list; Markdown engines wrap lines so long signatures become hard to scan.

A cleaner style is a definition list (supported by GitHub-flavoured MD):

**setWindow(window: TabbedBrowserWindow | null)**  
Attaches the tab’s view…

**loadURL(url: string, replace?: boolean)**  
Loads the specified URL…

This preserves monospace formatting for the signature while keeping the description on a new line.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~68-~68: Loose punctuation mark.
Context: ...dow(window: TabbedBrowserWindow | null)`: Attaches the tab's view to a given wind...

(UNLIKELY_OPENING_PUNCTUATION)

---

[uncategorized] ~69-~69: Loose punctuation mark.
Context: ...loadURL(url: string, replace?: boolean)`: Loads the specified URL in the tab. If ...

(UNLIKELY_OPENING_PUNCTUATION)

---

[uncategorized] ~70-~70: Loose punctuation mark.
Context: ...rorPage(errorCode: number, url: string)`: Loads a custom error page for the given...

(UNLIKELY_OPENING_PUNCTUATION)

---

[uncategorized] ~71-~71: Loose punctuation mark.
Context: ...al URL. - setLayout(layout: TabLayout): Sets the tab's layout configuration and...

(UNLIKELY_OPENING_PUNCTUATION)

---

[uncategorized] ~72-~72: Loose punctuation mark.
Context: ...and updates the view. - updateLayout(): Recalculates and applies the view's bou...

(UNLIKELY_OPENING_PUNCTUATION)

---

[style] ~72-~72: To form a complete sentence, be sure to include a subject.
Context: ...current layout and window dimensions. Should be called when the window resizes or la...

(MISSING_IT_THERE)

---

[uncategorized] ~73-~73: Loose punctuation mark.
Context: ... or layout changes. - updateTabState(): Reads the current state (title, URL, lo...

(UNLIKELY_OPENING_PUNCTUATION)

---

[uncategorized] ~74-~74: Loose punctuation mark.
Context: ...f changed, false otherwise. - show(): Makes the tab's view visible. - `hide()...

(UNLIKELY_OPENING_PUNCTUATION)

---

[uncategorized] ~75-~75: Loose punctuation mark.
Context: ...Makes the tab's view visible. - hide(): Hides the tab's view. - destroy(): Cl...

(UNLIKELY_OPENING_PUNCTUATION)

---

[uncategorized] ~76-~76: Loose punctuation mark.
Context: ...(): Hides the tab's view. - destroy()`: Cleans up resources, removes the view, ...

(UNLIKELY_OPENING_PUNCTUATION)

---

86-90: Misleading “Internal Helpers” headline

Everything under this section is still part of the public interface because it is documented here.
Either:

1. Move these helpers to a dedicated “Internal design notes” page that’s excluded from generated API docs, or
2. Mark them with a disclaimer such as “⚠️ Internal – subject to change without notice”.

Otherwise library users may assume long‑term stability and tight‑couple to them.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~88-~88: Loose punctuation mark.
Context: ...nal Helpers - createWebContentsView(): Factory function used internally by the...

(UNLIKELY_OPENING_PUNCTUATION)

---

[uncategorized] ~89-~89: Loose punctuation mark.
Context: ...ipt, session). - setupEventListeners(): Sets up listeners on the webContents ...

(UNLIKELY_OPENING_PUNCTUATION)

electron/browser/window.ts (1)

74-81: Duplicate full‑screen events in rapid succession

Both Electron’s "enter-full-screen" and "leave-full-screen" events can fire multiple times on some platforms.
Debounce or ignore duplicates to prevent flooding listeners (e.g. React state updates). A simple timestamp check or lodash.throttle wrapper would suffice.

vite/public/edge-surf-game-v1/resources/js/cr.js (2)

11-13: Remove redundant "use strict" directive

ES modules (or code transpiled/bundled as modules) are automatically executed in strict‑mode, so the explicit directive is unnecessary and flagged by Biome.
Keeping it may look harmless, but multiple redundant directives across bundled files add noise and can even confuse some concatenation tools.

-  'use strict';

🧰 Tools

🪛 Biome (1.9.4)

[error] 12-12: Redundant use strict directive.

The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.
Safe fix: Remove the redundant use strict directive.

(lint/suspicious/noRedundantUseStrict)

---

[error] 11-11: This variable is used before its declaration.

The variable is declared here:

(lint/correctness/noInvalidUseBeforeDeclaration)

---

213-223: Deprecated __defineGetter__/__defineSetter__ usage

These non‑standard APIs are deprecated and disallowed in strict ESLint
configs. Modern browsers (and Node) support Object.defineProperty
everywhere.

The surrounding comment hints at a future migration; consider prioritising it,
otherwise bundlers that tree‑shake “restricted‑properties” break builds.

electron/browser/tabs/tab.ts (1)

304-308: electron-context-menu expects a BrowserWindow, not WebContents

Passing webContents works at runtime only because the library loosely
checks the object shape, but TypeScript will flag this and future API
changes could break it. Supply the parent window instead:

-contextMenu({ window: webContents });
+contextMenu({ window: this.window.window });

vite/public/edge-surf-game-v1/resources/css/interface.css (1)

287-289: Empty style rule can be removed

#notify-shareText {} is empty and triggers Biome’s noEmptyBlock.
Delete it or add the missing declarations.

-#notify-shareText {
-}

🧰 Tools

🪛 Biome (1.9.4)

[error] 287-288: An empty block isn't allowed.

Consider removing the empty block or adding styles inside it.

(lint/suspicious/noEmptyBlock)

electron/browser/tabs/tab-manager.ts (2)

244-253: Unbounded activation‑history may grow indefinitely

spaceActivationHistory is appended on every activation but never pruned.
Long‑running sessions with many tabs/groups can accumulate thousands of entries and increase memory usage.

Consider capping the history per space or periodically pruning invalid IDs:

-    history.push(idToStore);
+    history.push(idToStore);
+    const MAX_HISTORY = 50; // configurable
+    if (history.length > MAX_HISTORY) {
+      history.splice(0, history.length - MAX_HISTORY);
+    }

---

651-667: Remove unused changed flag

The local variable changed is written but never read, generating dead code and minor cognitive overhead.

-    let changed = false;
     for (const [key, history] of this.spaceActivationHistory.entries()) {
       …
-        changed = true; // Mark that a change occurred (optional)
       }
     }
-    // Method doesn't need to return anything, just modifies the map
+    // No return value needed
   }

docs/references/omnibox.md (1)

182-189: Minor grammar fix: “Machine‑Learning‑based”

“There is no complex cross‑provider scoring or Machine Learning model…”

Prefer hyphenation for compound adjectives:

- Machine Learning model
+ machine‑learning model

🧰 Tools

🪛 LanguageTool

[grammar] ~185-~185: Did you mean “to”?
Context: ...vider scoring or Machine Learning model as found in browsers like Chrome. - **Dedu...

(LEARN_NNNNS_ON_DO)

electron/browser/browser.ts (1)

22-25: Avoid duplicate references to the same manager

private readonly tabManager is already declared (line 22). Exposing it publicly again through public tabs (line 24) creates two mutable references that can easily diverge if someone accidentally re‑assigns one of them. Prefer a single readonly field:

-  private readonly tabManager: TabManager;
-  private _isDestroyed: boolean = false;
-  public tabs: TabManager;
+  public readonly tabs: TabManager;
+  private _isDestroyed = false;

This keeps the surface area minimal and eliminates the risk of state drift.

electron/preload.ts (1)

11-33: Cache the permission matrix

checkCanUseAPI() re‑evaluates location and allocates a fresh object every time a wrapper is called. Given the large number of wrappers, this is unnecessary overhead. Compute once at module load and reuse:

const CAN_USE = computePermissions();
function computePermissions() { ... }
function can(api: keyof typeof CAN_USE) {
  return CAN_USE[api];
}

Replace checkCanUseAPI().browser with can("browser"), etc.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro