v3/internal/commands/appimage_testfiles/main.go (1)

53-59: 🛠️ Refactor suggestion

Mixed window-creation APIs – finish the migration

app.Windows.New() is correctly used here, but the same file still contains multiple calls to the old helpers (app.NewWebviewWindowWithOptions) further down (e.g. lines 86-110, 115-198). Leaving a mixture of both APIs undermines the goal of a clean break and will mislead developers studying the example.

-			app.NewWebviewWindowWithOptions(application.WebviewWindowOptions{ ... })
+			app.Windows.NewWithOptions(application.WebviewWindowOptions{ ... })

Please update every remaining occurrence in this file.

v3/examples/plain/main.go (1)

27-36: ⚠️ Potential issue

Return value from NewWithOptions is silently ignored

app.Windows.NewWithOptions(...) returns the newly-created *application.WebviewWindow (and in many helpers also an error). Swallowing these values loses an opportunity to:

1. handle window-creation errors early, and
2. keep a handle to the window for subsequent API calls.

-window := app.Windows.NewWithOptions(application.WebviewWindowOptions{ ... })
+window, err := app.Windows.NewWithOptions(application.WebviewWindowOptions{ ... })
+if err != nil {
+    log.Fatal(err)
+}
+_ = window   // or store it if you need it later

v3/examples/clipboard/main.go (1)

23-30: ⚠️ Potential issue

app.NewMenu() was removed – use the new manager API

The PR deprecates direct constructors; menu creation should go through the Menus manager:

-menu := app.NewMenu()
+menu := app.Menus.New()

Compilation will fail otherwise.

docs/src/content/docs/learn/systray.mdx (1)

110-118: 🛠️ Refactor suggestion

Update window-creation example to the new Manager API

The snippet still calls the removed app.NewWebviewWindow() helper.
To compile after the API break, replace it with the Windows manager variant:

-// Create a window
-window := app.NewWebviewWindow()
+// Create a window
+window := app.Windows.New()

v3/examples/systray-menu/main.go (1)

55-60: ⚠️ Potential issue

Switch to app.Menus.New() – app.NewMenu() no longer exists after the refactor

The new API groups menu functionality under the Menus manager. Using the old constructor will not compile.

-myMenu := app.NewMenu()
+myMenu := app.Menus.New()

v3/examples/dialogs/main.go (1)

28-34: 🛠️ Refactor suggestion

Menu construction uses deprecated helper

app.NewMenu() was removed; use the manager instead to prevent a build break:

-// Create a custom menu
-menu := app.NewMenu()
+// Create a custom menu
+menu := app.Menus.New()

v3/examples/build/main.go (1)

49-56: 🛠️ Refactor suggestion

Still using deprecated app.NewMenu() helper

All other changes moved to manager accessors (app.Menus.*). For consistency and to avoid removal-time breakage, replace with app.Menus.New().

-	menu := app.NewMenu()
+	menu := app.Menus.New()

docs/src/content/docs/guides/menus.mdx (1)

291-299: ⚠️ Potential issue

Out-of-date window API in example

app.NewWebviewWindowWithOptions predates the manager refactor.
Replace with:

window, _ := app.Windows.NewWithOptions(application.WebviewWindowOptions{
    Title: "Custom Menu Window",
    Windows: application.WindowsWindow{
        Menu: customMenu,
    },
})

Ensures all examples consistently use the new Windows manager.

v3/examples/window/main.go (1)

30-38: ⚠️ Potential issue

Possible nil-pointer dereference

application.Get().Windows.Current() can return nil if no window is focused; the subsequent Position() call would panic.
Either reuse the currentWindow helper or add a guard:

win := application.Get().Windows.Current()
if win == nil {
    return
}

v3/internal/generator/testcases/out_of_tree/main.go (1)

39-39: Same unused return value issue as flagged in variable_single_from_function/main.go

This line has the identical problem – see earlier comment for details and recommended fix.

v3/internal/generator/testcases/function_from_imported_package/main.go (1)

43-43: Unused return from Windows.New()

Replicates the compilation issue already pointed out; apply the _ = … or variable assignment fix here as well.

v3/internal/generator/testcases/struct_literal_multiple_files/main.go (1)

18-18: Unused return from Windows.New()

Same concern as in the previous files – update accordingly.

v3/internal/generator/testcases/struct_literal_single/main.go (1)

197-197: Unused return from Windows.New()

Duplicate of the issue already raised; please correct here as well to keep the test-cases compiling.

v3/examples/badge-custom/main.go (1)

77-83: Ditto for "set:badge" listener

Apply the same pattern as above.

v3/examples/badge/main.go (2)

63-69: Store unsubscribe for "remove:badge" listener

Same recommendation as in the custom-badge example.

---

70-76: Store unsubscribe for "set:badge" listener

Same recommendation as above.

docs/src/content/docs/learn/screens.mdx (1)

365-368: Same shadowing issue in isValidHTTPURL helper

Rename the parameter or alias the import to avoid url.Parse ambiguity, mirroring the correction proposed for the browser guide.

v3/internal/generator/testcases/variable_single/main.go (1)

29-29: *Capture or explicitly discard the returned Window to avoid linter noise

Windows.New() returns a *application.Window. Most static-analysis tools (e.g. staticcheck, errcheck) will flag the ignored result.
Either capture it for later use or assign it to _ with an explanatory comment.

-	app.Windows.New()
+	// Initialise the main window – discard handle if not needed.
+	_ = app.Windows.New() // nolint:errcheck,unused

v3/internal/generator/testcases/function_from_nested_imported_package/main.go (1)

42-42: Same note: don’t silently drop the *Window returned by Windows.New()

Consider:

-	app.Windows.New()
+	_ = app.Windows.New() // keep for future use or document intentional discard

v3/internal/generator/testcases/embedded_interface/main.go (1)

43-43: Window handle is ignored

If the window instance isn’t required, discard it explicitly to keep linters quiet; otherwise store it for later interaction.

-	app.Windows.New()
+	_ = app.Windows.New()

v3/internal/generator/testcases/function_single_internal/main.go (1)

53-53: Explicitly handle the value returned from Windows.New()

-	app.Windows.New()
+	_ = app.Windows.New() // or `mainWin := …` if needed later

v3/internal/generator/testcases/struct_literal_multiple_other/main.go (1)

41-41: Avoid dropping the returned window without comment

-	app.Windows.New()
+	_ = app.Windows.New() // intentional ignore

v3/internal/generator/testcases/complex_json/main.go (1)

116-116: Unused window instance

If the created window instance is needed later (e.g., to manipulate size, title, etc.), keep a reference:

-	app.Windows.New()
+	win := app.Windows.New()
+	_ = win // remove or use later

If truly unused (e.g., tests that only need a default window), ignore this suggestion.

v3/internal/generator/testcases/enum/main.go (1)

66-66: Ensure method chaining isn’t required

Previous API allowed chaining (app.NewWebviewWindow().On...).
If any following code expected the returned window for further configuration, capture it after switching to the manager API.

v3/examples/events-bug/main.go (1)

31-40: API migration correct; consider naming returned windows

Migration to app.Windows.NewWithOptions() is accurate.
Optional: assign the returned *WebviewWindow to a variable (e.g., win1 := …) if you later need to reference it (events, state, etc.).
Purely a readability nit – ignore if not required in this demo.

v3/examples/html-dnd-api/main.go (1)

26-33: Consider handling the returned window / error
app.Windows.NewWithOptions() returns a Window and possibly an error. In an example it’s fine to ignore them, but in production it’s safer to:

1. capture the window if you later need to manipulate it;
2. check the error to avoid a silent failure.

-window, _ := app.Windows.NewWithOptions(application.WebviewWindowOptions{ … })
+if wnd, err := app.Windows.NewWithOptions(application.WebviewWindowOptions{ … }); err != nil {
+    log.Fatal(err)
+} else {
+    _ = wnd // use if needed
+}

v3/examples/raw-message/main.go (1)

29-37: Same note on ignored return values
For consistency with the new manager API, capture and check the error returned by NewWithOptions. Skipping it risks masking runtime issues (e.g. invalid options on some platforms).

v3/pkg/application/dialogs_linux.go (2)

4-8: Minor redundancy after GetByID change
Windows.GetByID() already tells you whether a window was found via the second bool result. Immediately checking window != nil duplicates that information. If you keep the nil-check, drop the unused bool; otherwise:

-window, _ := globalApplication.Windows.GetByID(a.getCurrentWindowID())
-if window != nil {
+if window, ok := globalApplication.Windows.GetByID(a.getCurrentWindowID()); ok {
     parent, _ = window.(*WebviewWindow).NativeWindowHandle()
 }

---

26-31: Apply the same simplification here
Replicate the ok pattern in linuxDialog.show() to keep the codebase consistent.

v3/examples/window-api/main.go (1)

26-35: Handle NewWithOptions result
Same remark as in the other examples: capture the returned (Window, error) to surface construction failures.

v3/internal/generator/testcases/map_keys/main.go (1)

299-299: Consider capturing the returned window for clarity

app.Windows.New() returns a *application.WebviewWindow.
Even if you don’t need it immediately, assigning it to a variable (or the blank identifier) documents intent and avoids the impression of an ignored result.

-	app.Windows.New()
+	_ = app.Windows.New() // returned window currently unused

v3/internal/generator/testcases/function_single/main.go (1)

32-32: Capture or intentionally discard the returned window

Similar to the earlier test case, app.Windows.New() returns a window pointer. Assigning it (or using _) makes the ignored value explicit:

-	app.Windows.New()
+	_ = app.Windows.New()

v3/internal/commands/appimage_testfiles/main.go (1)

63-71: Minor: avoid hidden slice growth

Appending to hiddenWindows inside the WindowClosing hook without bounds or deduplication may leak memory if users repeatedly open/close windows. Consider using a map[*application.WebviewWindow]struct{} or checking contains before appending.

v3/examples/services/main.go (1)

58-61: Window pointer is discarded – consider retaining it for later use

app.Windows.NewWithOptions(...) returns a *application.WebviewWindow.
Although not strictly required for this example, keeping the pointer enables future window customisation (title updates, event hooks, etc.) and avoids creating an unreachable object.

-app.Windows.NewWithOptions(application.WebviewWindowOptions{
+mainWindow := app.Windows.NewWithOptions(application.WebviewWindowOptions{
     Width:  1024,
     Height: 768,
 })
+_ = mainWindow       // remove or use as needed

v3/examples/dialogs-basic/main.go (1)

26-33: Mixed old/new menu creation style – consider uniform Manager API

You’ve migrated window creation (app.Windows.NewWithOptions) but still rely on the convenience method app.NewMenu().
For full consistency and discoverability, use the Menus manager:

-// Create main menu
-menu := app.NewMenu()
+// Create main menu
+menu := app.Menus.New()

(Assumes Menus.New() is exposed; if not, keep as-is.)

v3/examples/gin-example/main.go (1)

96-100: Leaking event handler – store and defer the unsubscribe function

Events.On returns an unsubscribe callback.
Ignoring it means the handler is never removed and will stay alive for the whole app lifetime, which is fine for this tiny sample but is a bad pattern for real-world code or long-running apps.

-app.Events.On("gin-button-clicked", func(event *application.CustomEvent) {
+off := app.Events.On("gin-button-clicked", func(event *application.CustomEvent) {
     log.Printf("Received event from frontend: %v", event.Data)
 })
+defer off() // unregister on shutdown

v3/examples/window-menu/main.go (1)

40-58: Propagate window-creation error

NewWithOptions may fail; make the sample robust:

- app.Windows.NewWithOptions(application.WebviewWindowOptions{ … })
+ if _, err := app.Windows.NewWithOptions(application.WebviewWindowOptions{ … }); err != nil {
+     log.Fatal(err)
+ }

v3/examples/badge-custom/main.go (3)

59-68: Check result of NewWithOptions

Same concern as other examples—handle possible errors.

---

70-76: Unsubscribe handle ignored for "remove:badge"

Store the off function so the listener can be removed if the window is closed/recreated.

---

88-93: Potential goroutine leak – stop the ticker on app quit

The infinite loop keeps running after all windows are closed.
Listen for app.OnQuit (or similar) or use a context.Context to cancel.

v3/examples/badge/main.go (2)

52-61: Handle window creation error

Propagate or log the error returned by NewWithOptions.

---

81-85: Gracefully stop the broadcaster goroutine

Consider cancelling the loop on application shutdown to avoid stray goroutines.

v3/examples/systray-basic/main.go (1)

36-40: Prefer a symbolic key-constant instead of the raw "F12" string

Hard-coding "F12" makes the binding less self-documenting and more error-prone if the key name ever changes. If the framework already exposes key constants (e.g. application.KeyF12 or similar), swap the literal for the constant to improve discoverability and avoid typos.

v3/examples/contextmenus/main.go (1)

38-45: Consistent embed patterns increase readability

Earlier examples embed all assets via //go:embed assets/*, whereas this file uses //go:embed assets. Both are valid, but adopting one style across examples avoids confusion for newcomers skimming the repo.

v3/examples/menu/main.go (3)

59-65: Cache the current window instead of calling app.Windows.Current() twice

Calling app.Windows.Current() twice inside the same callback costs an extra bridge hop and risks returning nil if the active window changes in-between (highly unlikely but possible when menus trigger window focus changes). Grab the pointer once for clarity and safety.

-    if app.Windows.Current().Resizable() {
-        app.Windows.Current().SetResizable(false)
+    w := app.Windows.Current()
+    if w == nil {
+        return // no window – nothing to resize
+    }
+    if w.Resizable() {
+        w.SetResizable(false)
...
-        app.Windows.Current().SetResizable(true)
+        w.SetResizable(true)

---

147-147: Prefer app.Menus.Apply() over Set() for clarity

Menus.Set() mutates global state; a more descriptive name such as Apply (used in internal API docs) avoids confusion with assigning a menu instance. If both names exist, consider switching for consistency or deprecating one of them.

---

149-149: Naming nit – unused variable warning in linters

window := app.Windows.New() is only used for the fluent call; the local variable isn’t referenced afterwards except to call SetMenu. Either inline the expression or use _ to silence “unused variable” warnings in stricter linters.

-window := app.Windows.New().SetBackgroundColour(application.NewRGB(33, 37, 41))
-window.SetMenu(menu)
+app.Windows.
+    New().
+    SetBackgroundColour(application.NewRGB(33, 37, 41)).
+    SetMenu(menu)

v3/examples/notifications/main.go (1)

71-72: Handle possible emit failure

Same concern as above: ignore result only if you deliberately don’t care. Otherwise:

-    app.Events.Emit("notification:action", result.Response)
+    if _, err := app.Events.Emit("notification:action", result.Response); err != nil {
+        app.Logger.Error("emit failed", "err", err)
+    }

v3/examples/systray-custom/main.go (2)

19-30: Double-check Hidden:true during window creation

Creating the systray window with Hidden: true then immediately calling window.Show() a few lines below is fine, but setting Hidden to false and dropping the extra Show() call removes one IPC round-trip.

No change required if you want the explicit call – mentioning for potential micro-optimisation.

---

53-53: Consider naming the tray variable tray instead of systemTray

Minor readability suggestion – the type already conveys it’s a system tray; shorter names make subsequent chained calls less verbose.

-systemTray := app.SystemTray.New()
+tray := app.SystemTray.New()

v3/examples/video/main.go (1)

30-39: Capture or intentionally discard the returned window

app.Windows.NewWithOptions(...) returns a *WebviewWindow.
If the example intends to manipulate the window later (show/hide, emit events, etc.), keep the handle:

win := app.Windows.NewWithOptions(application.WebviewWindowOptions{ ... })
_ = win // remove if used

If no interaction is needed, explicitly ignore the value (_) to document the intent.

v3/examples/events/main.go (1)

36-41: Busy-loop goroutine may block shutdown

Inside the ApplicationStarted handler an infinite for { ... Sleep } loop is spawned.
Because the goroutine is untracked and never terminates, app.Quit() will hang until the program exits forcibly on some platforms. Consider replacing it with a time.Ticker and stopping the ticker in a shutdown hook.

-	for {
-		app.Events.Emit("myevent", "hello")
-		time.Sleep(10 * time.Second)
-	}
+	ticker := time.NewTicker(10 * time.Second)
+	go func() {
+		for range ticker.C {
+			app.Events.Emit("myevent", "hello")
+		}
+	}()
+	app.OnShutdown(func() { ticker.Stop() })

v3/pkg/application/linux_cgo.go (4)

1282-1288: Prefer checking the ok flag returned by GetByID

window, ok := globalApplication.Windows.GetByID(uint(we.id))
if !ok {
    return
}

Explicitly using the boolean avoids ambiguity if GetByID ever returns (nil, true) or a non-nil stub.

---

1293-1315: Same ok-flag handling applies here

Replicate the ok check to avoid unnecessary type assertions when the window isn’t found.

---

1474-1481: Minor: early-exit pattern simplifies control flow

-window, _ := globalApplication.Windows.GetByID(windowId)
-if window == nil {
-    return C.gboolean(0)
-}
+window, ok := globalApplication.Windows.GetByID(windowId)
+if !ok {
+    return C.gboolean(0)
+}

---

1511-1518: Repeat of the ok-flag suggestion

Consistency across handlers makes the code easier to reason about and marginally faster.

v3/examples/gin-service/services/gin_service.go (2)

32-35: EventData struct appears unused

The new EventData type isn’t referenced anywhere in the service. If it’s only here for future use, consider documenting that intent; otherwise remove it to avoid dead-code noise.

---

150-161: Email validation is extremely naive

strings.Contains(email, "@") will accept many invalid addresses (e.g. "@", "foo@"). If correctness matters, switch to net/mail.ParseAddress or a dedicated validator package.

-import "strings"
+import (
+	"strings"
+	"net/mail"
+)
...
-	if !strings.Contains(newUser.Email, "@") {
+	if _, err := mail.ParseAddress(newUser.Email); err != nil {
 		c.JSON(http.StatusBadRequest, gin.H{"error": "Invalid email format"})
 		return
 	}

v3/pkg/application/browser_manager.go (1)

19-27: Add basic argument validation & context to errors

browser.OpenURL("")/OpenFile("") silently fails on some platforms. Guard against empty strings and provide clearer error context.

-import (
-	"github.com/pkg/browser"
-)
+import (
+	"fmt"
+	"github.com/pkg/browser"
+)
...
-func (bm *BrowserManager) OpenURL(url string) error {
-	return browser.OpenURL(url)
+func (bm *BrowserManager) OpenURL(url string) error {
+	if url == "" {
+		return fmt.Errorf("OpenURL: empty url")
+	}
+	return browser.OpenURL(url)
}
...
-func (bm *BrowserManager) OpenFile(path string) error {
-	return browser.OpenFile(path)
+func (bm *BrowserManager) OpenFile(path string) error {
+	if path == "" {
+		return fmt.Errorf("OpenFile: empty path")
+	}
+	return browser.OpenFile(path)
}

v3/examples/badge/frontend/bindings/image/color/models.ts (1)

42-45: Consider guarding JSON parsing errors

JSON.parse will throw on invalid input, crashing the caller. Wrapping it in try/catch and returning a typed error (or undefined) would be safer for consumer code.

docs/src/content/docs/learn/dialogs.mdx (2)

17-22: Nitpick – prefixing with Info() already returns a fully-configured dialog

Because app.Dialogs.Info() returns a builder that already carries the correct dialog type, naming the local variable dialog is fine; however, some examples inside the docs use more explicit names (infoDialog, questionDialog, …). Sticking to one convention improves readability for people copy-pasting snippets.

---

114-117: Minor API consistency – AttachToWindow accepts a window, not a manager

The example calls

dialog.AttachToWindow(app.Windows.Current())

which is correct, but a short sentence clarifying that app.Windows.Current() returns a Window (not another manager) would prevent confusion for newcomers reading the snippet in isolation.

v3/pkg/application/environment_manager.go (2)

22-33: EnvironmentManager.Info() duplicates expensive OS queries

operatingsystem.Info() and em.app.platformEnvironment() might each probe the system (file I/O, shell exec). If Info() is called frequently you can cache the result:

 type EnvironmentManager struct {
     app *App
+    cachedInfo *EnvironmentInfo
 }
 ...
 func (em *EnvironmentManager) Info() EnvironmentInfo {
-    info, _ := operatingsystem.Info()
-    ...
-    return result
+    if em.cachedInfo != nil {
+        return *em.cachedInfo
+    }
+    info, _ := operatingsystem.Info()
+    ...
+    em.cachedInfo = &result
+    return result
 }

This keeps the API unchanged while avoiding redundant work.

---

36-41: Nil-impl guard good – but document behaviour

IsDarkMode() silently returns false when app.impl is nil. Add a short comment or godoc sentence so users know a false result can also mean “not initialised yet”.

v3/examples/badge/frontend/bindings/github.com/wailsapp/wails/v3/pkg/services/badge/models.ts (1)

40-54: Generated helper loses type-safety for unknown keys

Object.assign(this, $$source) blindly copies all properties, so typos slip through unnoticed. For generated models you can enforce strictness:

for (const key of Object.keys($$source)) {
  if (!(key in this)) {
    throw new Error(`Unknown property '${key}' supplied to Options`);
  }
}
Object.assign(this, $$source);

Not critical for generated code but improves DX when developers hand-craft JSON.

docs/src/content/docs/guides/menus.mdx (1)

417-420: Context-menu creation deviates from new pattern

After the refactor, creating a context menu without immediately registering it can confuse readers.
Consider showing:

contextMenu := app.ContextMenus.New()     // or .New("imageMenu")
app.ContextMenus.Add("imageMenu", contextMenu)

Aligns with the “manager owns creation” philosophy introduced elsewhere.

docs/src/content/docs/learn/context-menu.mdx (3)

13-17: Mismatch between recommendation and code sample

The text states “use the Add method from the ContextMenus manager”, yet the snippet still instantiates the menu with application.NewContextMenu() instead of the new, shorter helper app.ContextMenus.New().
Using app.ContextMenus.New() keeps the sample consistent with the manager-based guidance and avoids pulling in the (still valid but now secondary) application package function.

-contextMenu := app.ContextMenus.Add("menu-id", application.NewContextMenu())
+contextMenu := app.ContextMenus.Add("menu-id", app.ContextMenus.New())

---

26-39: Prefer the manager helper to emphasise the new pattern

Throughout the doc you alternate between application.NewContextMenu() and app.ContextMenus.New(). Sticking to one style (the manager helper) reduces cognitive load and shows the intended migration path.

Same applies to the registration comment – the two-step flow (New then Add) is clearer when both calls originate from app.ContextMenus.

---

112-117: Mixed creation styles within one document

application.NewContextMenu() resurfaces here; consider swapping to the manager helper for consistency and to reinforce the new API.

-contextMenu := application.NewContextMenu()
+contextMenu := app.ContextMenus.New()

v3/pkg/application/application_darwin.go (2)

238-242: Unused cancel-function from OnApplicationEvent

m.parent.Events.OnApplicationEvent returns a cancel function; ignoring it makes it impossible to detach the listener in long-running apps and may leak closures.
Store it (even if only to call in destroy() later) to avoid silent leaks.

- m.parent.Events.OnApplicationEvent(events.Mac.ApplicationDidFinishLaunching, func(*ApplicationEvent) {
+ cancel := m.parent.Events.OnApplicationEvent(events.Mac.ApplicationDidFinishLaunching, func(*ApplicationEvent) {
     // …
 })
 // TODO: call `cancel()` during shutdown if required

---

293-295: Repeated dark-mode lookup could be expensive

globalApplication.Env.IsDarkMode() may hit Objective-C each time the event fires.
If this event is frequent, cache the bool inside the event context (or Env) before broadcasting.

v3/examples/window/main.go (1)

670-676: Screen API now returns zero value on failure

app.Screens.GetPrimary() and GetAll() no longer surface an error. Consider checking for a zero‐initialised Screen (empty ID) before using the struct to prevent empty-dialog spam on headless setups.

docs/src/content/docs/learn/events.mdx (1)

431-439: Duplicated word & small grammar nit

The comment // Emit from a specific window sits immediately above window.EmitEvent – fine – but static analysis flags a repeated word (“window window” if rendered after line wrap).
Also consider mirroring the Manager API by using window.Events.Emit once the window manager exposes it, to keep messaging symmetrical.

-// Emit from a specific window
+// Emit from a specific window

🧰 Tools

🪛 LanguageTool

[duplication] ~437-~437: Possible typo: you repeated a word.
Context: ...ent", "hello") // Emit from a specific window window.EmitEvent("windowevent", "window specif...

(ENGLISH_WORD_REPEAT_RULE)

v3/examples/dev/go.mod (1)

8-15: New indirects: double-check necessity

Several new indirect dependencies (mergo, go-crypto, xdg, circl, filepath-securejoin) balloon the example’s module graph.
If they’re brought in only via the root wails upgrade you can prune them with go mod tidy -compat=1.22 once the upstream settles.

v3/pkg/application/key_binding_manager.go (1)

48-61: Expose immutable data from GetAll

GetAll returns a slice of pointers to the internally stored callbacks.
External packages can mutate the pointed-to struct fields, bypassing the lock and corrupting state.

-func (kbm *KeyBindingManager) GetAll() []*KeyBinding {
+func (kbm *KeyBindingManager) GetAll() []KeyBinding {
   …
-    result = append(result, &KeyBinding{ … })
+    result = append(result, KeyBinding{ … }) // value copy

docs/src/content/docs/learn/keybindings.mdx (1)

116-128: Normalise accelerator strings or document case-sensitivity

Accelerators are shown with mixed-case (“Cmd+S”, “Ctrl+S”).
KeyBindingManager.Add does not enforce normalisation, so "ctrl+s" and "Ctrl+S" register two distinct bindings. Either:

1. Internally canonicalise to a lower-case format, or
2. Explicitly state in the docs that accelerators are case-sensitive.

This avoids subtle duplicate or missed-binding bugs.

v3/examples/badge/frontend/bindings/github.com/wailsapp/wails/v3/pkg/services/badge/service.ts (2)

11-15: Remove unused import to avoid dead-code noise

$Create is imported but never referenced.
Even though the // @ts-ignore comment suppresses the TypeScript error, shipping unused symbols clutters the bundle and defeats tree-shaking.

-import { Call as $Call, CancellablePromise as $CancellablePromise, Create as $Create } from "@wailsio/runtime";
+import { Call as $Call, CancellablePromise as $CancellablePromise } from "@wailsio/runtime";

---

31-33: Missing JSDoc for newly added API

SetCustomBadge lacks the descriptive block that the other exported functions have. Generated bindings are part of the public surface; keep them self-documented for IDE tooltips and website generation.

+/**
+ * SetCustomBadge sets a badge with extended styling options.
+ * @param label   The text to display inside the badge.
+ * @param options Additional styling options (colour, font, etc.).
+ */
 export function SetCustomBadge(label: string, options: $models.Options): $CancellablePromise<void> {

docs/src/content/docs/learn/browser.mdx (2)

167-170: Compile-time name collision in example code

In isValidURL, the parameter url shadows the imported net/url package; url.Parse therefore fails to compile.

-func isValidURL(url string) bool {
-    parsed, err := url.Parse(url)
+func isValidURL(rawURL string) bool {
+    parsed, err := neturl.Parse(rawURL) // import net/url as neturl

Small detail, but examples copied verbatim should build.

---

505-505: Minor grammar – missing determiner

“showing them in a dialog” – add “the”/“a” as appropriate to improve readability.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~505-~505: You might be missing the article “the” here.
Context: ...perations fail, such as copying URLs to clipboard or showing them in a dialog for manual ...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

v3/pkg/application/event_manager.go (1)

33-41: Method names are fine – consider documenting cancellation semantics

On, Off, Reset work well but callers might miss that callbacks can call event.Cancel(). A short comment or example would aid discoverability.

v3/pkg/application/application.go (1)

311-313: Minor naming confusion

EventListener.callback func(app *ApplicationEvent) uses parameter name app, which shadows the App concept and can mislead readers. Recommend renaming to evt or event in a follow-up patch.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

Learnt from: nixpare
PR: wailsapp/wails#3763
File: v3/examples/keybindings/main.go:16-17
Timestamp: 2024-09-20T23:34:29.841Z
Learning: In the codebase, `application.Options.KeyBindings` uses the `application.Window` type, whereas `application.WebviewWindowOptions.KeyBindings` uses `*application.WebviewWindow`. This is intentional and acceptable.

v3/pkg/application/event_manager.go (1)

124-135: Slice returned after unlocking ⇒ data race persists (repeat of previous review)

You copy the map value after releasing the lock, leaving the underlying array unprotected; another goroutine doing append can mutate it and race with the loop below.

Same problem for hooks.

-	em.app.applicationEventListenersLock.RLock()
-	listeners, ok := em.app.applicationEventListeners[event.Id]
-	em.app.applicationEventListenersLock.RUnlock()
+	em.app.applicationEventListenersLock.RLock()
+	listeners, ok := em.app.applicationEventListeners[event.Id]
+	listeners = slices.Clone(listeners)
+	em.app.applicationEventListenersLock.RUnlock()

Apply the identical pattern a few lines later for hooks.

v3/pkg/application/messageprocessor.go (1)

56-60: Consider surfacing the “not found” boolean from Windows.GetByName

You ignore the second return value:

window, _ := globalApplication.Windows.GetByName(windowName)

If false is returned, you silently proceed with window == nil, which is later handled, but you lose the opportunity to log the exact reason (e.g., “window with name X not found”). Propagating that boolean into the error path would improve observability.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro