Fix(ActionBars): keys fire the wrong page after an in-combat Druid form change - #1983
Merged
EllesmereGaming merged 2 commits intoSep 7, 2026
Merged
Conversation
…-combat form change Reported by @Wiss (9.0.6): a new Druid shifts into Cat or Moonkin Form, the bar pages to the form abilities, but pressing a key casts the caster-page spell under it (Wrath), which shifts the character straight back out. The clips show that cycle every time a form is entered mid-fight. Action Bar 1 keys are the native ACTIONBUTTONn commands. Those fire Blizzard's own ActionButton1-12, which resolve their slot at click time from MainActionBar's actionpage attribute (CalculateAction via useparent-actionpage and the button's .bar link). Blizzard writes that attribute only from ActionBarController_UpdateAll, and only after walking PossessActionBar and the stock StanceBar, both of which this module has unregistered, reparented and stamped. Our own state driver pages the visible buttons independently, so when that Blizzard write does not land the icon shows page 7 while the key fires page 1. The MainBar _onstate-page handler now also writes the resolved page onto MainActionBar through a frame ref. It runs in the restricted environment, so the value is secure and the write is allowed in combat, and the native key can no longer disagree with the page the bar displays. Click-routed bars (custom paging, auto-paging opt-outs) are unaffected: their keys never consult MainActionBar.
Fold the rationale into the existing actionpage paragraph instead of a second block, drop the paired guards (MainActionBar is a FrameXML global), and run the mirror write after the ChildUpdate so a rejected write can never stop the bar's own repaging. Point the MainBarPageSync header at the mirror.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Bug: reported by @Wiss in EllesmereUI-helper Discord (2026-08-27)
Issue: A new Druid on 9.0.6 could use Cat Form or Moonkin Form abilities but not both: pressing a key showed the form's icon but cast a caster-page spell instead, shifting them straight back out. Clips showed the pattern on every shift.
Root cause: Action Bar 1 keys run through Blizzard's native ACTIONBUTTONn commands, which resolve their slot from MainActionBar's actionpage attribute in CalculateAction. Blizzard writes that attribute only from ActionBarController_UpdateAll, behind the stock Stance and Possess bars this addon has disposed of, so the write does not reliably land while EllesmereUI's own secure page driver keeps repaging the visible bar independently, and the icon and key fall out of sync.
Fix: CreateBarFrame's MainBar _onstate-page handler now mirrors the resolved page onto MainActionBar, run in the restricted environment so the write is secure and allowed in combat. Verified in-game: shifting into Cat Form mid-combat fires the Cat ability on key 1, and MainActionBar's actionpage reads 7 as expected.