Skip to content

Fix(ActionBars): keys fire the wrong page after an in-combat Druid form change - #1983

Merged
EllesmereGaming merged 2 commits into
EllesmereGaming:mainfrom
dfrisone:fix/ab-druid-form-paging
Sep 7, 2026
Merged

Fix(ActionBars): keys fire the wrong page after an in-combat Druid form change#1983
EllesmereGaming merged 2 commits into
EllesmereGaming:mainfrom
dfrisone:fix/ab-druid-form-paging

Conversation

@dfrisone

@dfrisone dfrisone commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

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.

cat transformation

…-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.
@EllesmereGaming
EllesmereGaming merged commit 58db4b0 into EllesmereGaming:main Sep 7, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants