fix: swal input type text#2336
Conversation
- Added 'swal-input-show' class to input fields in Wireless.php to ensure they are displayed correctly. - Modified CSS in jquery.sweetalert.css to hide default SweetAlert input fields while allowing specific ones to show (hiding was already done in legacy webgui)
WalkthroughUpdates the WiFi join/edit UI to add a swal-input-show class to several input fields via Wireless.php, and revises SweetAlert CSS to hide text inputs by default unless they carry this class. No server-side logic or control flow changes. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the "Integrations" page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
emhttp/plugins/dynamix/include/Wireless.php (1)
202-203: Auth inputs correctly opt-in to visibilityAdding swal-input-show to Username and Password ensures they remain visible under the new SweetAlert CSS. Password didn’t strictly need the class (rule hides only text inputs), but keeping it is harmless and future-proof.
emhttp/plugins/dynamix/styles/jquery.sweetalert.css (1)
181-185: Fix typo in comment“allow the ones we want to be show” → “allow the ones we want to be shown”.
Apply this minimal correction:
- /* this is a hack to prevent the default SWAL input from being shown, but allow the ones we want to be show */ + /* this is a hack to prevent the default SWAL input from being shown, but allow the ones we want to be shown */
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
emhttp/plugins/dynamix/include/Wireless.php(1 hunks)emhttp/plugins/dynamix/styles/jquery.sweetalert.css(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-06-02T21:51:01.477Z
Learnt from: zackspear
PR: unraid/webgui#2222
File: emhttp/plugins/dynamix/styles/jquery.sweetalert.css:610-640
Timestamp: 2025-06-02T21:51:01.477Z
Learning: In the Unraid webgui codebase, SweetAlert button styling is handled through CSS inheritance from general button selectors in default-base.css rather than component-specific `.sweet-alert button` selectors. SweetAlert buttons inherit styling from the general `button`, `button[type="button"]`, `input[type="button"]`, and `a.button` selectors.
Applied to files:
emhttp/plugins/dynamix/styles/jquery.sweetalert.css
🧬 Code Graph Analysis (1)
emhttp/plugins/dynamix/include/Wireless.php (1)
emhttp/plugins/dynamix/include/Helpers.php (1)
mk_option(182-184)
🔇 Additional comments (1)
emhttp/plugins/dynamix/include/Wireless.php (1)
209-230: No built-in SweetAlert text inputs found—coverage completeVerification results:
- No occurrences of
swal({... input: …}were detected in the codebase.- All custom text inputs in SweetAlert dialogs are now tagged with
swal-input-show.With no remaining built-in inputs at risk of being hidden, this change fully covers the surface area.
| /* this is a hack to prevent the default SWAL input from being shown, but allow the ones we want to be show */ | ||
| input[type="text"]:not(.swal-input-show) { | ||
| display: none; | ||
| -webkit-transition: all 0.3s; | ||
| transition: all 0.3s; | ||
| } | ||
|
|
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Narrow the selector to only hide the default SweetAlert input (safer scope)
As written, this hides every text input inside any SweetAlert unless it has swal-input-show. If any dialog embeds a custom text input without the new class, it will disappear.
Consider scoping to the default SweetAlert fieldset input (the library’s built-in prompt) while leaving other embedded form inputs alone. This reduces regression risk and still achieves your intent.
Proposed change:
- input[type="text"]:not(.swal-input-show) {
+ fieldset > input[type="text"]:not(.swal-input-show) {
display: none;
}Please spot-check a couple of SweetAlert dialogs that embed custom forms (beyond Wireless) to ensure their inputs remain visible after this change.
🏁 Script executed:
#!/bin/bash
set -e
echo "1. JavaScript files in emhttp/plugins/dynamix:"
find emhttp/plugins/dynamix -type f -name '*.js' || true
echo
echo "2. Occurrences of swal( with context:"
rg -n -A3 "swal\s*\(" emhttp/plugins/dynamix || true
echo
echo "3. Occurrences of html: (to spot custom form content):"
rg -n -C2 "html\s*:" emhttp/plugins/dynamix || trueLength of output: 324980
Restrict hidden inputs to SweetAlert’s built-in prompt only
We spot-checked all SweetAlert usages with custom HTML (e.g. the “Always Allow” checkbox in Wireless, progress dialogs in BodyInlineJS, etc.) and found no dialogs embedding a plain text input outside the library’s own prompt fieldset. It’s safe to scope the rule to only hide the default prompt input:
--- a/emhttp/plugins/dynamix/styles/jquery.sweetalert.css
+++ b/emhttp/plugins/dynamix/styles/jquery.sweetalert.css
@@ -181,7 +181,7 @@
/* hide all un-intended text inputs, but show our flagged ones */
- input[type="text"]:not(.swal-input-show) {
+ fieldset > input[type="text"]:not(.swal-input-show) {
display: none;
}Please apply this change to tighten the selector and avoid accidentally hiding other form inputs.
🤖 Prompt for AI Agents
In emhttp/plugins/dynamix/styles/jquery.sweetalert.css around lines 181-185, the
current rule hides all text inputs which may unintentionally hide non-SweetAlert
inputs; narrow the selector to only target SweetAlert's built-in prompt input by
scoping the rule to the SweetAlert modal/content and the library's prompt input
class (e.g., prefix the selector with the swal modal/content class and target
the swal prompt input class) so only the built-in prompt is hidden when it lacks
the .swal-input-show class.
3 participants
Summary by CodeRabbit