feat(v3): Add WindowMouseEnter/WindowMouseLeave events for tray popup windows

[leaanthony]

Summary

Implements mouse enter/leave events for windows on all three platforms (Windows, macOS, Linux), enabling tray popup windows to auto-focus when the mouse enters them.

• Added WindowMouseEnter and WindowMouseLeave common events
• Implemented FocusOnMouseEnter window option for automatic focus on mouse hover
• Added cross-platform mouse tracking that works even when windows are not focused
• Created mouse-hover example demonstrating the feature
• Updated event generation system to include standard Wails header comments
• Documented event generation process in AGENTS.md

Platform Implementation Details

• Windows: Uses WM_MOUSEMOVE with TrackMouseEvent API and WM_MOUSELEAVE
• macOS: Uses NSTrackingArea with NSTrackingActiveAlways flag via a MouseTrackingView overlay
• Linux: Uses GTK enter-notify-event and leave-notify-event signals

Closes #4887

Test plan

• Test mouse-hover example on Windows
• Test mouse-hover example on macOS
• Test mouse-hover example on Linux
• Verify events fire when window is not focused
• Verify FocusOnMouseEnter option works correctly
• Test with tray popup window use case

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

In general, the fix is to explicitly set a permissions block so that the GITHUB_TOKEN has only the minimal rights required. For read-only analysis jobs like detect-v2-changes and detect-v3-changes, contents: read is sufficient. Other jobs that create releases or tags may need contents: write and possibly packages: write or similar, but we should only grant those to the specific jobs that perform write operations, not globally.

The best fix here without changing functionality is to add a workflow‑level permissions block near the top of .github/workflows/automated-releases.yml, setting contents: read as the default for all jobs. The existing check-permissions job already declares permissions: {}, so it will remain with no token permissions, which is safe. Jobs that need elevated rights (e.g., release-v2, release-v3-alpha, or similar later in the file) can override the default in their own permissions section; since their code is not shown, we won’t touch them. This change satisfies CodeQL’s requirement for explicit permissions, limits the default GITHUB_TOKEN to read-only, and does not affect the existing behavior of the detection jobs, which only read git history and do not push changes.

Concretely:

• Edit .github/workflows/automated-releases.yml.
• Insert a permissions: block after the name: (or after the on: block, either is valid) that sets contents: read.
• Leave all existing job definitions unchanged, including check-permissions: permissions: {}.

In general, the problem is fixed by explicitly declaring a permissions block to limit the GITHUB_TOKEN to the minimal scopes required. This can be done at the workflow level (applies to all jobs) and overridden per job where more permissions are needed. For jobs that only read the repository (like detect-v2-changes and detect-v3-changes), contents: read is sufficient. For jobs that create or update releases/tags, you typically need contents: write (and potentially pull-requests: write or others if they modify PRs).

The best way to fix this specific workflow without changing functionality is:

• Add a workflow-level permissions: block setting a secure default, e.g. contents: read.
• Keep check-permissions’s existing permissions: {} (equivalent to no permissions) since it only runs shell code and uses github.actor from the event context.
• For release jobs that actually perform writes (e.g., release-v2 and release-v3), add per-job permissions: blocks that grant contents: write. This ensures detect-only jobs like detect-v3-changes (the one flagged by CodeQL) inherit only contents: read, satisfying the analyzer’s recommendation while preserving existing behavior.

Concretely:

• In .github/workflows/automated-releases.yml, above the env: block (after on:), insert a workflow-level permissions: block with contents: read.
• In the same file, add permissions: blocks to release-v2 and release-v3 jobs (once you reach their job definitions) granting contents: write. The snippet for release-v3 is elided, but you can still add the block at its job root. No new imports or external dependencies are required.

In general, the fix is to add explicit permissions: blocks to the workflow so that each job’s GITHUB_TOKEN has the minimum scopes it needs. Jobs that only check out code and run read-only checks can typically use contents: read. Jobs that push commits/tags or create releases must request contents: write. This makes the workflow’s security posture explicit and satisfies the CodeQL rule.

For this workflow, the minimal, non-breaking adjustment is:

• Add a workflow-level permissions: contents: read to give all jobs read-only access by default.
• Override that default for the release-v2 and release-v3 jobs, which actually perform write operations using GITHUB_TOKEN, by adding permissions: contents: write to those jobs.
• Jobs like check-permissions, detect-v2-changes, and detect-v3-changes only need to read repository contents and metadata, so they can safely use the inherited contents: read.

Concretely:

• At the top of .github/workflows/automated-releases.yml, right after name: Automated Nightly Releases, insert a permissions: block with contents: read.
• Within the release-v2: job definition (line 140 onward), add a permissions: block (e.g. between name: and runs-on:) setting contents: write.
• Do the same for the release-v3: job definition.

No additional imports or external packages are needed; this is purely a YAML configuration change.

To fix this, add explicit permissions blocks that grant only the scopes each job actually needs, instead of relying on implicit repository defaults. Since some jobs (like check-permissions) do not need the GITHUB_TOKEN at all, they can keep permissions: {}. Jobs that only read code (e.g., change-detection jobs, not fully shown) can be given contents: read. The release-v2 and release-v3 jobs, which commit, tag, push, and create releases, need contents: write and packages: write (for gh release create and any potential artifacts), plus pull-requests: write only if they actually modify PRs (not shown here, so we will not add it).

Concretely, in .github/workflows/automated-releases.yml, add a top-level permissions: block after name: that sets a safe default such as contents: read. Then, for the release-v2, release-v3, and summary jobs, add job-level permissions blocks tailored to their needs. release-v2 and release-v3 should get contents: write (they push commits/tags) and contents: read is implied by write; summary only writes to $GITHUB_STEP_SUMMARY, which does not require repo write scope, so it can inherit the default contents: read and does not need its own override. The CodeQL warning is specifically on release-v3, so we will explicitly add permissions to that job (and, for consistency, to release-v2 as well, since it performs similar operations). No new libraries or external dependencies are needed; this is purely a workflow YAML change.

In general, to fix this class of issue, add an explicit permissions block either at the workflow root (to affect all jobs) or on the specific job that doesn’t need broad access. The block should grant the minimum required privileges for what that job actually does. When a job only writes to the step summary or uses generic shell commands without authenticated GitHub operations, it can safely run with permissions: {} (no API permissions granted to GITHUB_TOKEN).

For this workflow, the minimal, non-disruptive change is to add a job-level permissions block to the summary job (starting at line 327). The summary job only writes to $GITHUB_STEP_SUMMARY and reads needs.* and github.* context variables, which do not require any GitHub API scopes. Therefore we can set permissions: {} for this job, mirroring the existing check-permissions job. Concretely, in .github/workflows/automated-releases.yml, under summary: (line 327), insert a permissions: {} line (properly indented) between name: Release Summary and runs-on: ubuntu-latest. No imports or additional steps are required.

In general, the problem is fixed by explicitly specifying a permissions: block either at the workflow root (applies to all jobs without their own permissions) or per job, assigning only the minimal privileges needed. For CI workflows that primarily run tests and manage artifacts, typical minimal permissions are contents: read and actions: write (for artifact operations). If no job needs to write to repository contents, issues, or PRs, those should be left at default (implicit none) or explicitly set to read/none.

For this specific workflow, the simplest and least disruptive fix is to define a workflow‑level permissions: block directly under the name: (before on:), granting contents: read so jobs can check out code, and actions: write so the cleanup job (and any others) can manage artifacts via the GitHub Actions API. No job appears to require write access to repository contents, issues, or pull requests, so we do not grant any extra scopes. This preserves existing functionality (checkout, artifact deletion) while constraining the GITHUB_TOKEN. Concretely, you would edit .github/workflows/build-and-test-v3.yml to insert:

permissions:
  contents: read
  actions: write

after the first line (name: Build + Test v3) and before the on: block. No additional imports or methods are required because this is purely a YAML configuration change.

In general, the fix is to add a permissions: block that explicitly scopes the GITHUB_TOKEN to the minimal set of permissions required. This is best done at the workflow root so that it applies to all jobs, unless specific jobs need different permissions. For this workflow, none of the shown jobs push commits, create releases, or manage issues/PRs; they primarily check approval state, build, test, and manipulate artifacts. Those activities only require read access to repository contents and (if needed) the default token access to artifacts, which is governed by actions and contents permissions. A safe and minimal configuration is to set contents: read at the workflow root. If any job later needs stronger permissions, it can override at the job level.

The single best fix without changing functionality is therefore: add a root���level permissions: block after the name: (or after on: if you prefer) with contents: read. This keeps all current behavior while ensuring the GITHUB_TOKEN is not accidentally granted write access. Concretely, in .github/workflows/build-and-test-v3.yml, insert:

permissions:
  contents: read

aligned at the root indentation, just after line 2 (the blank line after the workflow name). No additional imports or methods are needed, as this is a pure YAML configuration change.

In general, this should be fixed by explicitly declaring a permissions block either at the workflow root (applies to all jobs) or per job, with the least privileges required. Since test_templates only needs to read the repository contents and artifacts and does not appear to need write access to anything, giving it contents: read is sufficient. To avoid affecting other jobs which are not shown and might legitimately need broader permissions, we will add a job-level permissions block for test_templates only.

Concretely, in .github/workflows/build-and-test-v3.yml, under the test_templates: job definition (around line 187), insert a permissions: section between needs: [test_js, test_go] and runs-on: ${{ matrix.os }}. The block will specify contents: read. No imports or additional definitions are needed, as this is purely YAML configuration for GitHub Actions.

To fix the problem, explicitly declare restricted permissions for the detect job so that the GITHUB_TOKEN cannot perform unnecessary write operations. The job only needs to read repository contents to check out code and inspect changed files, so contents: read is sufficient.

The best targeted fix, without changing existing functionality, is:

• Add a permissions: section under the detect job, parallel to name, if, outputs, and runs-on.
• Set contents: read as a minimal scope, matching CodeQL’s suggested baseline.

Concretely, in .github/workflows/publish-npm.yml, between the outputs: block (line 14–15) and runs-on: ubuntu-latest (line 16), insert:

    permissions:
      contents: read

No additional imports or methods are needed because this is a workflow configuration change only.

To fix the problem, explicitly restrict the GITHUB_TOKEN permissions for this workflow or job. Since the job only prints a message and does not use the token at all, the safest and simplest approach is to disable the token entirely by setting permissions: { contents: none } or, more strictly, permissions: {} / permissions: none at the appropriate level, depending on desired clarity and compatibility.

The best way to fix this workflow without changing existing functionality is to add a permissions block at the workflow root (top level, alongside name and on). This will apply to all jobs in the workflow, including test. Because the job does not use GitHub APIs, we can safely set permissions: contents: read (a common minimal baseline) or fully disable access. To align with common recommendations while remaining conservative, we will set contents: read. Concretely, in .github/workflows/test-simple.yml, between the name: Test Simple and on: lines, insert:

permissions:
  contents: read

No additional methods, imports, or definitions are required; only this YAML edit is needed.

In general, the fix is to ensure that any path derived from r.URL.Path is constrained to stay within the intended assets directory. That means: join the user path with the base directory via filepath.Join, normalize to an absolute path, and then verify that it still resides under the assets root before using it with os.Stat or http.ServeFile. If the check fails, we should not serve a file from disk and should instead fall back to the default asset handler.

Concretely, in v3/examples/screen/main.go inside the middleware, we should:

1. Compute the base assets directory once: assetsDir := filepath.Join(dir, "assets").
2. Use filepath.Join(assetsDir, url) to combine the base and the requested path rather than string concatenation.
3. Resolve the result to an absolute path: absPath, err := filepath.Abs(path).
4. Resolve the base directory to an absolute path once as well and check that absPath is within that directory, using a prefix check that accounts for path separators (e.g., by ensuring strings.HasPrefix(absPath, assetsDirAbs+string(os.PathSeparator)) || absPath == assetsDirAbs).
5. Only if the normalization succeeds and the path is within the assets directory do we call os.Stat and http.ServeFile; otherwise, we should skip serving from disk and call next.ServeHTTP.

To implement this, we need to (a) adjust the existing dir, url, and path assignments, (b) introduce assetsDir and its absolute form, and (c) import the strings package to perform the prefix check. No other behavior of the application needs to change: valid asset paths will still be served from disk during development, and invalid or traversal attempts will be passed through to the bundled asset handler (or result in a normal 404 from that handler).

In general, the fix is to ensure that any path derived from user input is constrained to a safe directory. For this use-case, requests should only be able to access files inside the local assets directory. We should therefore (1) build paths using filepath.Join rather than raw string concatenation, (2) normalize the resulting path to an absolute path, and (3) verify that it still resides under the intended assets directory before using it with os.Stat or http.ServeFile. If the check fails, we should fall back to the existing bundled asset handler (next.ServeHTTP).

The best way to fix this without changing observable functionality is: compute an absolute, cleaned base path for assets once per request (assetsDir := filepath.Join(dir, "assets"), then assetsDirAbs := filepath.Clean(assetsDir)), then for each incoming URL path compute requestedPath := filepath.Join(assetsDirAbs, url) and requestedPathAbs := filepath.Clean(requestedPath). Reject or ignore the path if requestedPathAbs is not within assetsDirAbs (for example, using strings.HasPrefix on a path that is ensured to end with the separator), and in that case just call next.ServeHTTP(w, r). Only if the path is within the assets directory and exists on disk do we serve it directly. This will require importing strings and replacing the current dir + "/assets" + url logic in v3/examples/screen/main.go around lines 45–52.

Concretely:

• Add an import for "strings" to the existing import list.
• In the middleware, after obtaining dir, compute assetsDir := filepath.Join(dir, "assets") and assetsDirAbs := filepath.Clean(assetsDir).
• Replace path := dir + "/assets" + url with requestedPath := filepath.Join(assetsDirAbs, url) and requestedPathAbs := filepath.Clean(requestedPath).
• Before calling os.Stat or http.ServeFile, check that requestedPathAbs is under assetsDirAbs using a prefix check that accounts for path separators; if the check fails, call next.ServeHTTP(w, r) instead of serving from disk.

[sonarqubecloud]

Quality Gate failed

Failed conditions
183 Security Hotspots
19.4% Duplication on New Code (required ≤ 3%)
E Security Rating on New Code (required ≥ A)
D Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[cloudflare-workers-and-pages]

Deploying wails with    Cloudflare Pages

Latest commit:	423377f
Status:	✅  Deploy successful!
Preview URL:	https://9c2866c0.wails.pages.dev
Branch Preview URL:	https://vk-2cfc-investigate-mous.wails.pages.dev

View logs

[semgrep-code-wailsapp]

High severity vulnerability may affect your project—review required:
Line 569 lists a dependency (rollup) with a known High severity vulnerability.

ℹ️ Why this matters

Affected versions of rollup are vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').

References: GHSA, CVE

To resolve this comment:
Check if you use Rollup to bundle JavaScript with import.meta.url and the output format is set to cjs, umd, or iife formats, while allowing users to inject scriptless HTML elements with unsanitized name attributes.

• If you're affected, upgrade this dependency to at least version 3.29.5 at v3/examples/dev/frontend/package-lock.json.
• If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

[Nurysso]

Isn’t this behavior dependent on the WM/compositor? For example, on KWin (KDE), pointer enter/leave events are typically delivered, but focus-on-hover may be restricted, whereas compositors like Hyprland are more permissive.
How is this handled?