-
Notifications
You must be signed in to change notification settings - Fork 22
Web: Call preventDefault only when the plugin was enabled explicitly by setWebReturnValue #20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…by setWebReturnValue It was not possible to disable the behavior at the moment. Browsers understanding preventDefault() would always show the dialog as long as the plugin is enabled. Broken in commit 166df01.
WalkthroughModified the web beforeunload handler to conditionally invoke Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
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. Comment |
Summary of ChangesHello @saierd, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a bug in the web implementation of the window close plugin. Previously, the browser's default unload behavior was always prevented, leading to an inability to disable the 'stay on page' dialog. The change ensures that this prevention mechanism is only activated when the plugin has been explicitly configured to provide a return value for the unload event, restoring the intended control over the browser's behavior. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request addresses an issue where the 'before unload' confirmation dialog was always being shown on the web, regardless of whether it was configured. The change correctly moves the preventDefault() call inside the conditional check for _returnValue != null. This ensures that the confirmation dialog is only triggered when setWebReturnValue has been explicitly called with a non-null value, effectively fixing the bug and giving developers the expected control over this behavior. The implementation is correct and I approve of the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
lib/flutter_window_close_web.dart (1)
12-13: Docstring plugin name nitThe doc comment still says “FlutterHi plugin”, which doesn’t match the current plugin name. Consider updating it for clarity when you next touch this file.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
lib/flutter_window_close_web.dart(1 hunks)
🔇 Additional comments (1)
lib/flutter_window_close_web.dart (1)
26-37: Behavior change correctly gatespreventDefault()on explicit_returnValueMoving
unloadEvent.preventDefault()inside the_returnValue != nullguard ensures the unload dialog is only triggered when the plugin has been explicitly enabled viasetWebReturnValue. This matches the PR description and avoids the previous “always show dialog when plugin is active” behavior, while preserving the existingreturnValuelogic.Looks good and should be safe given
_returnValueis only set throughsetWebReturnValue.
It was not possible to disable the behavior at the moment. Browsers understanding preventDefault() would always show the dialog as long as the plugin is enabled.
Broken in commit 166df01.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.