* fix(v3/windows): Move browser flags to application-level options (#4559)
WebView2 shares a single browser environment per user data path, so
browser flags (EnabledFeatures, DisabledFeatures, AdditionalBrowserArgs)
must be set at application level, not per-window.
Changes:
- Add EnabledFeatures, DisabledFeatures, AdditionalBrowserArgs to
application.Options.Windows
- Mark per-window equivalents in WindowsWindow as deprecated
- Update webview_window_windows.go to read from app-level options
This fixes the crash when opening a second window with different
browser flags.
Fixes#4559
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: address PR review comments
- Remove incorrectly added WebviewGpuPolicy field from WindowsOptions
(it's a Linux-specific option that already exists in LinuxWindow)
- Clarify changelog: AdditionalLaunchArgs was renamed to AdditionalBrowserArgs
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* refactor!: remove per-window browser flags (breaking change)
BREAKING CHANGE: Remove EnabledFeatures, DisabledFeatures, and
AdditionalLaunchArgs from per-window WindowsWindow options.
Use application-level options instead:
- Options.Windows.EnabledFeatures
- Options.Windows.DisabledFeatures
- Options.Windows.AdditionalBrowserArgs
These flags apply globally to the shared WebView2 environment,
so per-window configuration was never actually supported.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* docs: add documentation for application-level browser flags
- Document EnabledFeatures, DisabledFeatures, AdditionalBrowserArgs
- Add examples showing how to configure WebView2 browser flags
- Explain that these flags apply globally to all windows
- Update application API reference with platform-specific options
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* chore: simplify browser flags documentation
Remove unnecessary warnings and overly prescriptive comments.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* docs: clarify that AdditionalBrowserArgs requires -- prefix
Chromium command-line switches require the -- prefix.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* feat(v3): Add UseApplicationMenu option for cross-platform menu support
Add `UseApplicationMenu` option to `WebviewWindowOptions` that allows
windows on Windows and Linux to inherit the application menu set via
`app.Menu.Set()`.
This provides a simpler cross-platform approach:
- On macOS: No effect (app menu is always global)
- On Windows/Linux: Window displays the application menu
Benefits:
- Eliminates need for platform-specific menu code
- Per-window opt-in maintains backwards compatibility
- Explicit window menus still take priority
Updated:
- webview_window_options.go: Added UseApplicationMenu bool field
- webview_window_windows.go: Check UseApplicationMenu when no window menu set
- webview_window_linux.go: Check UseApplicationMenu when no window menu set
- examples/dialogs: Use UseApplicationMenu instead of conditional SetMenu
- examples/menu: Use UseApplicationMenu instead of explicit SetMenu
- docs: Updated menu and window options documentation
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* docs: Remove incorrect 'Menu Options' section header
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Move window-specific JS/CSS injection from platform-specific execJS calls
to a unified approach using the runtime. The runtime now fetches
/wails/init.js and /wails/init.css from the asset server after signaling
ready, and the backend identifies which window made the request via the
existing x-wails-window-id header.
This fixes the bug where JS/CSS options were not executed when using URL
navigation (only worked with HTML option), and provides a single,
consistent implementation across all platforms.
Changes:
- Add middleware handlers for /wails/init.js and /wails/init.css
- Remove platform-specific JS/CSS injection from Windows, Linux, macOS
- Add init script loading to runtime JS (fire-and-forget)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix(v3): replace various debug logs from Info to Debug
* fix(v3): fixed logging on linux as well as windows
* fix(v3): add format directive for warning log argument
---------
Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
* fix(v3): overhaul drag-and-drop for Linux reliability and simplify Windows
This commit fixes drag-and-drop reliability on Linux and simplifies the
Windows implementation.
## Linux
- Rewrite GTK drag handlers to properly intercept external file drops
- Fix HTML5 internal drag-and-drop being broken when file drop enabled
- Add hover effects during file drag operations
- Fix multiple app instances interfering with each other
## Windows
- Remove native IDropTarget in favor of JavaScript approach (matches v2)
- File drops now handled via chrome.webview.postMessageWithAdditionalObjects
## All Platforms
- Rename EnableDragAndDrop to EnableFileDrop
- Rename data-wails-drop-target to data-file-drop-target
- Rename wails-drop-target-active to file-drop-target-active
- Add comprehensive drag-and-drop documentation
## Breaking Changes
- EnableDragAndDrop -> EnableFileDrop
- data-wails-dropzone -> data-file-drop-target
- wails-dropzone-hover -> file-drop-target-active
- DropZoneDetails -> DropTargetDetails
- Remove WindowDropZoneFilesDropped event (use WindowFilesDropped)
* feat(macos): optimize drag event performance with debouncing and caching
- Add 50ms debouncing to limit drag events to 20/sec (was 120/sec)
- Implement window implementation caching to avoid repeated lookups
- Maintain existing 5-pixel threshold for immediate response
- Keep zero-allocation path with pre-allocated buffers
- Rename linuxDragActive to nativeDragActive for clarity
- Update IMPLEMENTATION.md with optimization details and Windows guidance
Performance improvements:
- 83% reduction in event frequency
- ~6x reduction in CPU/memory usage during drag operations
- Maintains smooth visual feedback with InvokeSync for timer callbacks
* fix(windows): implement proper file drop support for Windows
- Remove incorrect AllowExternalDrag(false) call that was blocking file drops
- Fix message prefix from 'FilesDropped' to 'file:drop:' to match JS runtime
- Fix coordinate parsing for 'file:drop:x:y' format (indices 2,3 not 1,2)
- Add enableFileDrop flag injection to JS runtime during navigation
- Update JS runtime to check enableFileDrop flag before processing drops
- Always call preventDefault() to stop browser navigation on file drags
- Show 'no drop' cursor when file drops are disabled
- Update example to filter file drags from HTML drop zone handlers
- Add documentation for combining file drop with HTML drag-and-drop
* fix(v3): block file drops on Linux when EnableFileDrop is false
- Add disableDND() to intercept and reject external file drags at GTK level
- Show 'no drop' cursor when files are dragged over window
- Allow internal HTML5 drag-and-drop to work normally
- Initialize _wails.flags object in runtime core to prevent undefined errors
- Inject enableFileDrop flag on Linux and macOS (matching Windows)
- Fix bare _wails reference to use window._wails
- Update docs with info about blocked drops and combining with HTML DnD
* fix(darwin): add missing fmt import in webview_window_darwin.go
* fix(macOS): implement hover effects for file drag-and-drop with optimizations
- Added draggingUpdated: handler to track mouse movement during drag operations
- Implemented macosOnDragEnter/Exit/Over export functions for real-time hover state
- Fixed JS function call from '_wails.handlePlatformFileDrop' to correct 'wails.Window.HandlePlatformFileDrop'
- Added EnableFileDrop flag checks to prevent hover effects when file drops are disabled
- Renamed linuxDragActive to nativeDragActive for cross-platform consistency
Performance optimizations:
- Added 50ms debounce to reduce event frequency from ~120/sec to ~20/sec
- Implemented 5-pixel movement threshold for immediate response
- Added window caching with sync.Map to avoid repeated lookups
- Zero-allocation JavaScript calls with pre-allocated 128-byte buffer
- Reduced memory usage to ~18 bytes per event (6x reduction)
Build improvements:
- Updated runtime Taskfile to include documentation generation
- Added docs:build task to runtime build process
- Fixed build order: events → docs → runtime
Documentation:
- Added IMPLEMENTATION.md with optimization details
- Included guidance for Windows implementation
* chore(v3/examples): remove html-dnd-api example
The drag-n-drop example now demonstrates both external file drops
and internal HTML5 drag-and-drop, making this separate example redundant.
* docs(v3): move drag-and-drop implementation details to runtime-internals
- Add drag-and-drop section to contributing/runtime-internals.mdx
- Remove IMPLEMENTATION.md from example (content now in proper docs)
- Covers platform differences, debugging tips, and key files
* fix(v3): remove html-dnd-api from example build list
* fix(v3): remove duplicate json import in application_darwin.go
* fix(v3): address CodeRabbit review feedback
- Fix docs to use app.Window.NewWithOptions() instead of deprecated API
- Add mutex protection to dragOverJSBuffer to prevent race conditions
- Add mutex protection to dragThrottleState fields for thread safety
* docs: add coderabbit pre-push requirement to AGENTS.md
* fix(v3/test): use correct CSS class name file-drop-target-active
* chore(v3/test): remove dnd-test directory
This was a development test file that shouldn't be in the PR.
The drag-n-drop example serves as the proper test case.
* docs(v3): update Windows file drop comment to reflect implemented fix
Remove stale TODO - enableFileDrop flag is now injected in navigationCompleted
* refactor(v3): make handleDragAndDropMessage unexported
Internal method only called by application event loop, not part of public API.
* perf(v3): optimize JSON processing and reduce allocations in hot paths
- Switch to goccy/go-json for method binding, events, and HTTP transport
(21-63% faster, 40-60% less memory for method calls)
- Optimize BoundMethod struct layout to reduce padding (144 -> 136 bytes)
- Cache isVariadic flag at registration to avoid reflect call per invocation
- Use stack-allocated buffer for method arguments (<=8 args)
- Optimize result collection to avoid slice allocation for single return values
- Use sync.Map for MIME cache to improve concurrent read performance
- Use buffer pool for HTTP transport request body reading
- Lazily allocate CloseNotify channel in content type sniffer
- Remove debug CSS logging from asset server
- Add comprehensive benchmark tests (build tag: bench)
Performance improvements for BoundMethod.Call:
- SimpleCall: 1290ns -> 930ns (28% faster), 240B -> 80B (67% less memory)
- ComplexCall: 10500ns -> 3900ns (63% faster), 1192B -> 1020B (14% less)
- VariadicCall: 3460ns -> 1600ns (54% faster), 512B -> 289B (44% less)
* perf(v3): add max size limit to buffer pool to prevent memory bloat
Buffers larger than 512KB are not returned to the pool, allowing GC
to reclaim memory after large requests (e.g., base64 encoded images).
* perf(v3): remove mimetype library dependency, saving ~208KB binary size
- Replace github.com/wailsapp/mimetype with expanded extension map + stdlib
- Expand MIME type map from 16 to 50+ common web formats (fonts, audio, video, etc.)
- Add comprehensive test suite validating MIME detection for all web formats
- Use http.DetectContentType as fallback for unknown extensions
- Actual binary size reduction: 1.2MB (11MB -> 9.8MB in test app)
* perf(v3): migrate all runtime code to goccy/go-json
Migrate remaining encoding/json usages to goccy/go-json in:
- pkg/application (android, darwin, ios, single_instance, webview_window)
- pkg/services (kvstore, notifications on all platforms)
- internal/assetserver/webview (request/response handling)
- internal/runtime and internal/capabilities
Note: encoding/json (110KB) remains in binary because:
1. goccy/go-json imports it for interface compatibility (json.Marshaler, etc.)
2. log/slog (stdlib) uses it for JSON output
The performance benefit is in the hot paths which now use the faster library.
* perf(v3): replace gopkg.in/ini.v1 with minimal .desktop file parser
Replace the gopkg.in/ini.v1 dependency with a purpose-built minimal parser
for Linux .desktop files.
The new parser:
- Only extracts the Exec key from [Desktop Entry] section (all we need)
- Follows the Desktop Entry Specification
- Has comprehensive test coverage (40 tests) including:
- All major file managers (Nautilus, Dolphin, Thunar, PCManFM, Caja, Nemo)
- Edge cases (UTF-8, special chars, comments, empty files, etc.)
- Buffer limit handling
Binary size reduction: 45KB (10.22MB -> 10.18MB)
* perf(v3): remove samber/lo from runtime code, saving ~310KB binary size
Replace samber/lo with Go 1.21+ stdlib slices package and minimal internal
helpers in all runtime code paths. This removes 80 transitive dependencies
from the production binary.
Changes:
- Create internal/sliceutil package with Unique and FindMapKey helpers
- Replace lo.Without with slices.DeleteFunc in event handling
- Replace lo.Ternary with inline if/else in Windows code
- Replace lo.Uniq with sliceutil.Unique for feature flags
- Replace lo.FindKey with sliceutil.FindMapKey for method aliases
- Replace lo.Filter with slices.DeleteFunc in event listeners
- Replace lo.Must with inline panic in w32 package
Binary size: 10.18MB -> 9.87MB (~310KB / 3% reduction)
Note: CLI tools still use samber/lo since they don't affect
production binary size. The application_debug.go file also
retains lo usage as it has //go:build !production tag.
* fix: address CodeRabbit review comments
- Use application/x-typescript MIME type (not IANA-registered text/typescript)
- Fix potential panic in mimetype_stdlib_test.go for short MIME strings
- Use cached isVariadic flag in bindings_optimized_bench_test.go
* fix: initialize goccy/go-json decoder early to fix Windows test failure
On Windows, goccy/go-json's type address calculation can fail if the
decoder is first invoked during test execution rather than at init time.
Force early initialization by unmarshaling a []int during package init.
See: https://github.com/goccy/go-json/issues/474
* 📝 Add docstrings to `v3/performance-improvements` (#4844)
* fix: initialize goccy/go-json decoder early to fix Windows test failure
On Windows, goccy/go-json's type address calculation can fail if the
decoder is first invoked during test execution rather than at init time.
Force early initialization by unmarshaling a []int during package init.
See: https://github.com/goccy/go-json/issues/474
* 📝 Add docstrings to `v3/performance-improvements`
Docstrings generation was requested by @leaanthony.
* https://github.com/wailsapp/wails/pull/4843#issuecomment-3703472562
The following files were modified:
* `v3/internal/assetserver/common.go`
* `v3/internal/assetserver/content_type_sniffer.go`
* `v3/internal/assetserver/mimecache.go`
* `v3/internal/fileexplorer/desktopfile.go`
* `v3/internal/fileexplorer/fileexplorer_linux.go`
* `v3/internal/sliceutil/sliceutil.go`
* `v3/pkg/application/application_ios.go`
* `v3/pkg/application/bindings.go`
* `v3/pkg/application/ios_runtime_ios.go`
* `v3/pkg/w32/window.go`
---------
Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
---------
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
All tests pass. Let me provide a summary of the changes.
## Summary
This issue (#4012) is about **Dynamic Context Menu** support, labeled as a Bug affecting macOS.
### Root Cause Analysis
I identified two related issues:
1. **macOS Memory Leak**: In `webview_window_darwin.go`, the `openContextMenu` function created a **new** `macosMenu` and `NSMenu` every time a context menu was displayed, ignoring any existing `menu.impl`. This caused:
- Memory leaks (NSMenu objects never released)
- Wasted CPU cycles rebuilding the native menu each time
- Inconsistent behavior with other platforms
2. **Windows Memory Leak**: In `webview_window_windows.go`, the `openContextMenu` function created a new `Win32Menu` each time without destroying the previous one, leaking Windows menu handles.
### Fixes Applied
**1. macOS (`v3/pkg/application/webview_window_darwin.go:889-897`):**
```go
func (w *macosWebviewWindow) openContextMenu(menu *Menu, data *ContextMenuData) {
// Reuse existing impl if available, otherwise create new one
if menu.impl == nil {
menu.impl = newMenuImpl(menu)
}
thisMenu := menu.impl.(*macosMenu)
thisMenu.update()
C.windowShowMenu(w.nsWindow, thisMenu.nsMenu, C.int(data.X), C.int(data.Y))
}
```
This now:
- Reuses existing `menu.impl` if available (consistent with Linux)
- Only creates new impl on first display
- The `update()` call still rebuilds native items from current Go state for dynamic updates
**2. Windows (`v3/pkg/application/webview_window_windows.go:1174-1184`):**
```go
func (w *windowsWebviewWindow) openContextMenu(menu *Menu, _ *ContextMenuData) {
// Destroy previous context menu if it exists to prevent memory leak
if w.currentlyOpenContextMenu != nil {
w.currentlyOpenContextMenu.Destroy()
}
// Create the menu from current Go-side menu state
thisMenu := NewPopupMenu(w.hwnd, menu)
thisMenu.Update()
w.currentlyOpenContextMenu = thisMenu
thisMenu.ShowAtCursor()
}
```
This now properly destroys the old `Win32Menu` before creating a new one.
**3. Updated `v3/UNRELEASED_CHANGELOG.md`** with fix entries.
### Files Changed
- `v3/pkg/application/webview_window_darwin.go`
- `v3/pkg/application/webview_window_windows.go`
- `v3/UNRELEASED_CHANGELOG.md`
### Testing
- Build passes ✓
- All existing tests pass ✓
- Manual testing recommended using `v3/examples/contextmenus` app
Fix not enough memory error when initialising drag and drop on windows
Co-authored-by: Andraz Vrhovec <andraz@koofr.net>
Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
* fix: use structured logging for debug/info methods
The debug() and info() methods were using fmt.Sprintf() which expects
printf-style format directives, but callers were using slog-style
key-value pairs. Changed to pass args directly to Logger.Debug/Info
which properly handles structured logging.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
* docs: add changelog entries for build fixes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
* chore: remove temporary debug print statements from mobile merge
Remove emoji debug logs (🔴, 🟢, 🟠, 🔵, 🔥) that were accidentally left in
from the iOS/Android mobile platform support merge. These were development
debugging statements that should not have been included in the final code.
Files cleaned:
- application.go
- application_debug.go
- init_android.go
- init_ios.go
- mainthread_android.go
- mainthread_ios.go
- webview_window.go
- webview_window_ios.go
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* docs: add changelog entries for debug cleanup and breaking change
- Add breaking change note: production builds are now default
- Add entry for debug print statement removal
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: convert remaining printf-style debug calls to slog-style
Convert three debug() calls that were still using printf-style format
strings to slog-style structured logging (key-value pairs):
- systemtray_windows.go: ShellNotifyIcon show/hide failures
- application_darwin.go: window lookup failure
This addresses CodeRabbit review feedback and ensures consistency
with the refactored debug() method.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: convert all printf-style info() calls to slog-style
Convert remaining info() calls that were using printf-style format
strings to slog-style structured logging (key-value pairs):
- application_ios.go: iOS log messages and HandleJSMessage calls
- webview_window_windows.go: WM_SYSKEYDOWN logging
- application.go: handleWindowMessage and handleWebViewRequest logging
Also removed debug fmt.Printf statements from handleWebViewRequest.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: add build tag to main.m to prevent Go from compiling it on non-iOS platforms
Go's toolchain tries to process .m (Objective-C) files when they're in a
directory with Go files. Adding a //go:build ios tag tells Go to only
process this file when building for iOS, matching how darwin .m files
handle this (e.g., //go:build darwin && !ios).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* chore: remove orphaned wails-mimetype-migration submodule reference
The iOS merge added a submodule reference without a corresponding
.gitmodules file, causing Cloudflare and other CI systems to fail
with "No url found for submodule path" errors.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: auto-disable DMA-BUF renderer on Wayland with NVIDIA to prevent crashes
WebKitGTK has a known issue with the DMA-BUF renderer on NVIDIA proprietary
drivers running Wayland, causing "Error 71 (Protocol error)" crashes.
This fix automatically detects NVIDIA GPUs (via /sys/module/nvidia) and sets
WEBKIT_DISABLE_DMABUF_RENDERER=1 when running on Wayland.
Also removes leftover debug print statements from mobile platform merge.
See: https://bugs.webkit.org/show_bug.cgi?id=262607🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: add NVIDIA driver info to wails3 doctor on Linux
Shows NVIDIA driver version and srcversion in doctor output to help
diagnose Wayland/NVIDIA compatibility issues.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
* Add support for origin tracking in raw message handling
- Implemented origin and top origin tracking for web messages from JavaScript.
- Updated `RawMessageHandler` to include `originInfo`.
- Added cross-platform support for retrieving the origin of messages in macOS, Windows, and Linux.
* fix build
* fix build
* fix build
* fix build
* fix build
* Fix nil checks and string handling for message origins across platforms
- Ensure proper fallback to empty strings for `origin` and `topOrigin` when errors or nil values are encountered.
- Normalize handling of `message.body` to account for non-NSString values in macOS.
* add docs
* Remove unused doc
* update changelog
* fix build
---------
Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
* Fix Windows build error with go-webview2 v1.0.22
Fixes#4513
The go-webview2 library changed the MessageCallback signature in v1.0.22
from `func(string)` to `func(message string, sender *ICoreWebView2, args *ICoreWebView2WebMessageReceivedEventArgs)`.
This caused a build error for users:
```
cannot use w.processMessage (value of type func(message string)) as
func(message string, sender *ICoreWebView2, args *ICoreWebView2WebMessageReceivedEventArgs)
value in assignment
```
Changes:
- Updated processMessage signature to match go-webview2 v1.0.22
- Upgraded go-webview2 dependency from v1.0.21 to v1.0.22
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
* Fix Windows build error with go-webview2 v1.0.22
Fixes#4513
The go-webview2 library changed the MessageCallback signature in v1.0.22
from `func(string)` to `func(message string, sender *ICoreWebView2, args *ICoreWebView2WebMessageReceivedEventArgs)`.
This caused a build error for users:
```
cannot use w.processMessage (value of type func(message string)) as
func(message string, sender *ICoreWebView2, args *ICoreWebView2WebMessageReceivedEventArgs)
value in assignment
```
Changes:
- Updated processMessage signature to match go-webview2 v1.0.22
- Upgraded go-webview2 dependency from v1.0.21 to v1.0.22
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
* fix: prevent white window flash when Hidden option is true
Fixes#4611
When creating a window with Hidden: true, the window was briefly
visible as a white window before disappearing. This was caused by
CreateWindowEx using WS_OVERLAPPEDWINDOW style which includes
WS_VISIBLE by default.
The fix excludes WS_VISIBLE from the window style when the Hidden
option is set to true, ensuring the window remains invisible until
explicitly shown via window.Show().
* Update Changelog
* Fix SetBackgroundColour on Windows
Update Chromium window color on calls to SetBackgroundColour.
* update changelog
* v3.0.0-alpha.23
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* feat: Add Content Protection for Windows and macOS
- Prevents window contents from being captured by screen recording/sharing software
- Windows: Uses WDA_EXCLUDEFROMCAPTURE on Windows 10 2004+, falls back to WDA_MONITOR
- macOS: Uses NSWindowSharingType to set window as read-only for screen sharing
- Added ContentProtectionEnabled option to WebviewWindowOptions
- Added SetContentProtection() method for runtime control
- Added comprehensive documentation and example usage
* fix changelog.mdx
* Misc fixes
* Misc fixes
* Update v3/pkg/w32/user32.go
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
* Remove debug line
---------
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
* fix: v3-alpha WindowUnMinimise not fired when window is maximized ( Windows )
* add fix to changelog.mdx
* Apply suggestion from @coderabbitai[bot]
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
---------
Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
* new events
* macOS dnd improvements
* wailsio adds for dropzone
* update example
* sorta working
the top 300px of the window are not dropabble for some reason i suspect it has to do with the drag enter/drag leave xy as the performOperation needed to use the ContentView for appropriate X/Y
* implement attribute detection for data-wails-dropzone
* docs
* pass x/y dnd linux
* cleanup exmample
* changelog
* pass all attributes to golang on dragdrop
* filetree example
* fix dnd build windows
* Fix windows dnd
* update docs
* remove debug log
* appease the security bot
* Fix changelog
* Fix changelog
* Revert "Fix event generation issues."
This reverts commit ae4ed4fe
* Fix events
* Fix merge conflicts. Fix events generation formatting
* Update docs
* Fix duplicate bundledassets import causing build failures
Remove duplicate import of bundledassets package that was causing
compilation errors in PR #4318. The import was declared twice in
the same import block, causing "bundledassets redeclared" errors.
Fixes build issues in GitHub Actions for drag-and-drop zones feature.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* Replace fmt.Printf debug statements with globalApplication.debug
Replace all fmt.Printf debug logging statements in drag-and-drop
functionality with proper globalApplication.debug calls. This provides:
- Consistent logging with the rest of the application
- Proper key-value structured logging
- Better integration with the application's logging system
- Cleaner debug output format
Changes:
- application_darwin.go: Replace 2 fmt.Printf calls
- webview_window.go: Replace 6 fmt.Printf calls
- webview_window_windows.go: Replace 13 fmt.Printf calls
- Remove unused fmt import from application_darwin.go
All debug messages maintain the same information but now use
structured logging with key-value pairs instead of printf formatting.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* Add nil checks to WindowEventContext methods
Ensure all WindowEventContext methods properly handle nil c.data
by initializing the map when it's nil. This prevents panics when
methods are called on contexts that haven't been properly initialized.
Changes:
- DroppedFiles(): Add nil check and map initialization
- setCoordinates(): Add nil check and map initialization
- setDropZoneDetails(): Add nil check and map initialization
- DropZoneDetails(): Add nil check and map initialization
All methods now follow the same pattern as setDroppedFiles()
where a nil data map is automatically initialized to prevent
runtime panics during drag-and-drop operations.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* Update v3/pkg/application/webview_window_darwin.m
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
* reinstate events docs.
---------
Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
* fix(windows): disable external drag only when EnableDragAndDrop is set
* update changelog for html dnd fix
* remove redundant commented out code for windows dnd
* Fix changelog
---------
Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
Co-authored-by: Atterpac <89053530+atterpac@users.noreply.github.com>
* Adding the ability to pass custom args to windows webview2
---------
Co-authored-by: Jason Gibson <jason@harbingerinteractive.com>
Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
* fix incorrect window destroy
* remove duplicate common signals
* Better handling of "shouldclose"
* Better handling of "shouldclose"
* Fix ABI safety issues in exported function for macOS window closing
Address CodeRabbit feedback on ABI safety and data races:
- Change exported function signature to use C types (C.uint, C.bool) for ABI safety
- Convert unconditionallyClose field from bool to atomic uint32 for thread safety
- Update all read/write operations to use atomic operations across platforms
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Fixes two Windows-specific compilation issues that were preventing
GitHub Actions builds from passing:
## Issues Fixed
### 1. chromium.PutIsVisible undefined error
- **Problem**: Method call `chromium.PutIsVisible(true)` not available in
current go-webview2 package version
- **Solution**: Commented out the call with TODO note for future restoration
- **File**: pkg/application/webview_window_windows.go:1686-1690
- **Impact**: Temporarily disables efficiency mode prevention until method available
### 2. Variable redeclaration error
- **Problem**: `err` variable redeclared with `:=` in same function scope
- **Solution**: Changed second assignment from `:=` to `=` for proper reassignment
- **File**: pkg/application/systemtray_windows.go:65
- **Context**: iconIsInTrayBounds assignment in positionWindow function
## Additional Changes
- Added CLAUDE.md for development guidance
- Added API_MANAGERS.md documenting new manager-based API structure
- Implemented functional DMG package creation (internal/commands/dmg/)
- Restored DMG support in CLI tool with proper validation
## Verification
- ✅ Commands package builds successfully
- ✅ Main CLI builds successfully
- ✅ Tests run without compilation errors
- ✅ Example builds pass
Resolves GitHub Actions Windows build failures introduced in recent commits.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Addresses the issue where application windows fail to show on Windows 10 Pro
due to efficiency mode preventing WebView2 NavigationCompleted events.
## Changes Made
### Windows (webview_window_windows.go)
- **Decouple window container from WebView state**: Window now shows immediately
- **Add timeout fallback**: 3-second timeout to show WebView if navigation is delayed
- **Prevent efficiency mode**: Set WebView2 IsVisible=true per Microsoft recommendation
- **Enhanced state tracking**: Added showRequested, visibilityTimeout, windowShown fields
- **Robust navigation completion**: Improved handler to work with new visibility logic
### macOS (webview_window_darwin.go)
- **Documentation**: Added comment noting macOS already follows best practices
- **No functional changes**: macOS implementation already robust
### Linux (webview_window_linux.go, linux_cgo.go, linux_purego.go)
- **Add missing methods**: Implemented show()/hide() methods in main Linux file
- **CGO implementation**: Added windowShow()/windowHide() delegation methods
- **Purego implementation**: Added windowShow()/windowHide() methods for purego builds
- **Consistent behavior**: Matches CGO implementation with position saving
## Implementation Pattern
Adopts the following pattern:
1. **Separate concerns**: Window container vs WebView content readiness
2. **Immediate visibility**: Show window container immediately
3. **Progressive enhancement**: Show WebView content when ready
4. **Robust fallbacks**: Timeout and multiple strategies for edge cases
## Testing Considerations
- Windows 10 Pro efficiency mode scenarios
- WebView2 navigation delays or failures
- Cross-platform consistency
- Performance impact of timeout mechanisms
Fixes#2861🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
