You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixes#86: PDForm registers a browser beforeunload prompt when the form becomes dirty (ConfirmOnUnload, default true), but DisposeAsync never unregistered it. Any page that disposed a dirty PDForm (for example by internal navigation) left the unconditional "Exit and lose changes?" prompt installed on the whole browser tab until a full page reload.
Change
DisposeAsync now calls setUnloadListener(Id, false) before disposing the JS module, guarded by ConfirmOnUnload, catching JSDisconnectedException for the case where the browser or circuit is already gone. This matches the teardown idiom already used by PDModal. Removing an id that was never armed is a no-op in the JS module, so the call is safe unconditionally.
The issue's optional belt-and-braces suggestion (path-aware JS listener) was deliberately not taken: it would suppress legitimate prompts for a form that survives navigation, for example one hosted in a shared layout, which is a behaviour change beyond the bug.
Verification
Reproduced and verified in the PanoramicData.Blazor.Web Blazor Server host:
Instrumented window.addEventListener/removeEventListener to log beforeunload handler changes by function name.
Edited a field on /pdform4 (default ConfirmOnUnload): logged add:beforeUnloadListener.
Navigated internally away via a plain anchor (bypassing PDNavLink's NavigationCancelService confirm): with this fix the disposal logged remove:beforeUnloadListener, and a synthetic beforeunload dispatch confirmed no prompt remains armed.
A dirty PDForm arms the shared "Exit and lose changes?" beforeunload
listener via setUnloadListener, but DisposeAsync never removed the
form's id, so internal navigation away from a dirty form left the
prompt installed on the whole tab until a full page reload.
DisposeAsync now best-effort disarms the listener before disposing the
JS module, swallowing JSDisconnectedException for the case where the
browser or circuit is already gone (matching the PDModal teardown
idiom).
Verified in the Blazor Server demo host on /pdform4: the listener is
added on first edit and now removed when navigation disposes the form,
with no stale prompt remaining.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
AI Reviewer: run a review on demand. To trigger the first review automatically, go to your organization or repository integration settings. AI can make mistakes. Always validate suggestions.
TIP This summary will be updated as you push new changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #86: PDForm registers a browser beforeunload prompt when the form becomes dirty (ConfirmOnUnload, default true), but DisposeAsync never unregistered it. Any page that disposed a dirty PDForm (for example by internal navigation) left the unconditional "Exit and lose changes?" prompt installed on the whole browser tab until a full page reload.
Change
DisposeAsync now calls setUnloadListener(Id, false) before disposing the JS module, guarded by ConfirmOnUnload, catching JSDisconnectedException for the case where the browser or circuit is already gone. This matches the teardown idiom already used by PDModal. Removing an id that was never armed is a no-op in the JS module, so the call is safe unconditionally.
The issue's optional belt-and-braces suggestion (path-aware JS listener) was deliberately not taken: it would suppress legitimate prompts for a form that survives navigation, for example one hosted in a shared layout, which is a behaviour change beyond the bug.
Verification
Reproduced and verified in the PanoramicData.Blazor.Web Blazor Server host:
add:beforeUnloadListener.remove:beforeUnloadListener, and a synthetic beforeunload dispatch confirmed no prompt remains armed.Library builds clean (0 warnings, 0 errors).
🤖 Generated with Claude Code