mirror of
https://github.com/pi-hole/web.git
synced 2026-08-23 06:39:09 +01:00
4959620022
Found via manual verification of every page: two places set up tabs using the Bootstrap 3 pattern of putting the "active" state on the <li> wrapper (and, for the domains page, only in aria-expanded) rather than on the <a>/tab-link element itself. Bootstrap 5's Tab component tracks the active tab exclusively via the "active" class on the link, so with neither page marking any link "active" at load, Tab.js could never find a previous tab to deactivate - clicking a different tab just added a second active pane on top of the first instead of replacing it. - groups-domains.lp: the Domain/RegEx filter tabs. Added class="active" to the initially-selected tab's <a>, and swapped the stale Bootstrap 3/4 "in" class for "show" on its pane (harmless leftover, but dead code once "active" is what actually matters). Also fixed groups-domains.js's addDomain(), which was reading aria-expanded="true" to figure out which tab is active - Bootstrap 5 never touches that attribute for plain tabs (only aria-selected/the active class), so that lookup would have always resolved to the Domain tab even when the RegEx tab was showing, silently misfiling regex entries as exact-domain ones. Switched it to read the .active class instead. - settings-advanced.js: the All Settings page's topic pills (DNS/DHCP/NTP/etc.). Same fix - add "active" to the first pill's <a> in both the initial-load and "only changed settings" code paths. Verified against a live container: groups/domains now correctly shows only one tab's content at a time and addDomain() resolves to the right tab; settings/all now correctly switches between topic panes instead of stacking them, confirmed via the pane class list before/after a real click. Zero console errors. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Adam Warner <me@adamwarner.co.uk>