Retail 12.0.5: OverrideActionBarButton1-6 still update after ConsolePort_Bar hides OverrideActionBar

[jcll]

I'm seeing taint/error spam on Retail 12.0.5 with ConsolePort_Bar enabled.

ConsolePort_Bar hides OverrideActionBar in ConsolePort_Bar/Controller/Blizzard/Retail.lua, but the child buttons OverrideActionBarButton1 through OverrideActionBarButton6 still seem to remain registered and receive Blizzard action button updates. In my case, this was repeatedly hitting OverrideActionBarButton2Cooldown.

Example error:

...Blizzard_ActionBar/Shared/ActionButton.lua:847: bad argument #1 to 'SetCooldown'
(Usage: self:SetCooldown(start, duration [, modRate]).
Secret values are only allowed during untainted execution for this argument.)

[Blizzard_ActionBar/Shared/ActionButton.lua]:866: in function 'ActionButton_ApplyCooldown'
[Blizzard_ActionBar/Shared/ActionButton.lua]:842: in function 'ActionButton_UpdateCooldown'
[Blizzard_ActionBar/Shared/ActionButton.lua]:571: in function 'Update'
[Blizzard_ActionBar/Shared/ActionButton.lua]:544: in function 'UpdateAction'
[Blizzard_ActionBar/Shared/ActionButton.lua]:975: in function 'OnEvent'

Locals:
cooldown=OverrideActionBarButton2Cooldown
start=<no value>
duration=<no value>
enable=true
modRate=<no value>

I also saw this earlier in the same session:

[ADDON_ACTION_BLOCKED] AddOn 'ConsolePort_Bar' tried to call the protected function 'OverrideActionBarButton2:SetAttribute()'.

This looks separate from #179. That issue had the same SetCooldown cascade, but from MICRO_BUTTONS causing toolbar initialization to abort. This one still happens after that path is no longer the problem, and the affected cooldown frame is specifically OverrideActionBarButton2Cooldown.

The relevant bit in Retail.lua currently hides the override bar frame:

OverrideActionBar = true;

but unlike the main bar and multibars, it does not also call hideActionButton() on the actual override buttons.

This local patch stopped the errors for me after reload:

for i = 1, 6 do
    hideActionButton(_G['OverrideActionBarButton' .. i])
end

I added it right after the HUD frame hiding loop in env.UIHandler:HideBlizzard().

Environment:

• WoW Retail 12.0.5.67314
• ConsolePort 3.1.38
• ConsolePort_Bar enabled

I don't know if there are other side effects to hiding those buttons this way, but it matches how the file already handles ActionButton1..12 and the multibar buttons.

[Gateswong]

Some more example errors from my end:

3x [ADDON_ACTION_BLOCKED] AddOn 'ConsolePort_Bar' tried to call the protected function 'MultiBarLeftButton1:SetShown()'.
[!BugGrabber/BugGrabber.lua]:540: in function '?'
[!BugGrabber/BugGrabber.lua]:524: in function <!BugGrabber/BugGrabber.lua:524>
[C]: in function 'SetShown'
[Blizzard_ActionBar/Shared/ActionBar.lua]:206: in function 'UpdateShownButtons'
[Blizzard_ActionBar/Shared/ActionButton.lua]:548: in function 'UpdateAction'
[Blizzard_ActionBar/Shared/ActionButton.lua]:975: in function 'OnEvent'
[Blizzard_ActionBar/Shared/ActionButton.lua]:223: in function <...ceBlizzard_ActionBar/Shared/ActionButton.lua:220>


Locals:
self=<table>
event="ADDON_ACTION_BLOCKED"
addonName="ConsolePort_Bar"
addonFunc="MultiBarLeftButton1:SetShown()"
name="ConsolePort_Bar"
badAddons=<table>{
 ConsolePort_Bar=true
}
L=<table>{
 NO_DISPLAY_2="|cffffff00The standard display is called BugSack, and can probably be found on the same site where you found !BugGrabber.|r"
 ERROR_DETECTED="%s |cffffff00captured, click the link for more information.|r"
 BUGGRABBER_STOPPED="|cffffff00There are too many errors in your UI. As a result, your game experience may be degraded. Disable or update the failing addons if you don't want to see this message again.|r"
 USAGE="|cffffff00Usage: /buggrabber <1-%d>.|r"
 STOP_NAG="|cffffff00!BugGrabber will not nag about missing a display addon again until next patch.|r"
 NO_DISPLAY_STOP="|cffffff00If you don't want to be reminded about this again, run /stopnag.|r"
 NO_DISPLAY_1="|cffffff00You seem to be running !BugGrabber with no display addon to go along with it. Although a slash command is provided for accessing error reports, a display can help you manage these errors in a more convenient way.|r"
 ERROR_UNABLE="|cffffff00!BugGrabber is unable to retrieve errors from other players by itself. Please install BugSack or a similar display addon that might give you this functionality.|r"
 ADDON_CALL_PROTECTED="[%s] AddOn '%s' tried to call the protected function '%s'."
}

Also this from blizzard stock UI but it seems related:

65577x ...ceBlizzard_ActionBar/Shared/ActionButton.lua:847: bad argument #1 to 'SetCooldown' (Usage: self:SetCooldown(start, duration [, modRate]). Secret values are only allowed during untainted execution for this argument.)
[Blizzard_ActionBar/Shared/ActionButton.lua]:847: in function <...ceBlizzard_ActionBar/Shared/ActionButton.lua:845>
[Blizzard_ActionBar/Shared/ActionButton.lua]:866: in function 'ActionButton_ApplyCooldown'
[Blizzard_ActionBar/Shared/ActionButton.lua]:842: in function 'ActionButton_UpdateCooldown'
[Blizzard_ActionBar/Shared/ActionButton.lua]:571: in function 'Update'
[Blizzard_ActionBar/Shared/ActionButton.lua]:1062: in function 'OnEvent'
[Blizzard_ActionBar/Shared/ActionButton.lua]:333: in function <...ceBlizzard_ActionBar/Shared/ActionButton.lua:310>


Locals:
cooldown=OverrideActionBarButton2Cooldown <ActionButtonTemplate.xml:111>{
 _MSQ_Color=<table>
}
start=<no value>
duration=<no value>
enable=true
modRate=<no value>

[FailMaven]

Same thing on Classic Era 1.15.9 (ConsolePort 3.1.44, full suite, CP_Bar
"Crossbar: Triple" preset), so this doesn't look Retail-specific. Same dispatch
path as yours, ending in SetAttribute rather than the cooldown call:

[ADDON_ACTION_BLOCKED] AddOn 'ConsolePort' tried to call the protected function 'MultiBarBottomRightButton8:SetAttribute()'.
[C]: in function 'SetAttribute'
[Blizzard_ActionBar/Shared/ActionButton.lua]:521: in function 'UpdatePressAndHoldAction'
[Blizzard_ActionBar/Shared/ActionButton.lua]:593: in function 'Update'
[Blizzard_ActionBar/Shared/ActionButton.lua]:544: in function 'UpdateAction'
[Blizzard_ActionBar/Shared/ActionButton.lua]:975: in function 'OnEvent'
[Blizzard_ActionBar/Shared/ActionButton.lua]:223: in function <...ceBlizzard_ActionBar/Shared/ActionButton.lua:220>

(BugGrabber frames and locals trimmed.)

Note that mine blames ConsolePort and Gateswong's blames ConsolePort_Bar for what
looks like the same mechanism, so the addon name in these reports doesn't seem
trustworthy.

Cosmetic here since the spell fires normally, only the BugSack count climbs.

Probed the blocked button in-game, which may narrow it:

• IsShown() false, GetAttribute('statehidden') true - HideBlizzard worked.
• IsEventRegistered('ACTIONBAR_SLOT_CHANGED') false - UnregisterAllEvents stuck.
• HookScript('OnEvent') never fires while the error keeps reproducing, so the
  button's own OnEvent script isn't running. Something calls the mixin method
  directly.
• ActionBarButtonEventsFrame.frames: array, 103 entries, button at index 20.
  That frame has no UnregisterFrame.
• ActionBarActionEventsFrame.frames: hash, button present. Has UnregisterFrame.
• GetActionBarToggles() returns false for all four multibars.

Two fixes I tried that did NOT work, in case it saves anyone time:

1. ActionBarActionEventsFrame:UnregisterFrame(button) inside hideActionButton.
   Button was still in that table at runtime afterward, error unchanged.
2. Commenting out the SetAttributeNoHandler('action', i) loop in
   Model/Game/Actionbar.lua. No effect. (Side note: with it disabled the CP_Bar
   display was pixel-identical for me.)

The bit I found most interesting: GetActionBarToggles() was already false for
both bars, so HideBlizzard is running Hide/UnregisterAllEvents/SetAttribute/
SetParent over bars the client had already disabled maybe tainting those buttons for
no benefit?

Also can't explain why ActionButton1-12 get identical treatment, can never be
disabled, and yet have never thrown this for me.

No patch proposed, obvi. Happy to run checks on Era 1.15.9 if that's useful.

[FailMaven]

Follow-up with more data, including a correction to how I framed the first
comment.

New capture, on a bar ConsolePort_Bar never hides:

  [ADDON_ACTION_BLOCKED] AddOn 'ConsolePort' tried to call the protected
  function 'MultiBar5Button12:SetAttribute()'

MultiBar5 is commented out of the hide list in ConsolePort_Bar's Classic.lua, so
that button is never hidden, unregistered, reparented, or given statehidden. Same
for Gateswong's MultiBarLeftButton1 above. So this isn't only about buttons on
bars CP hides, which is how I'd been reading it.

More useful: I think I've pinned the trigger. The blocked button is the one
holding the action whose state just changed; not the button pressed, and not
modifier-related.

• Drain Soul on RT+Down (Bar 3 slot 8) blocks MultiBarBottomRightButton8.
• Moving Drain Soul to LT+Down (Bar 3 slot 4) blocks MultiBarBottomRightButton4
  instead. Same input, different slot: the error follows the spell.
• A pet/dismount macro on RT+Z blocks MultiBar5Button12, which holds Summon
  Felsteed and sits on a different bar than the macro. That macro's [mod:ctrl]
  branch contains /dismount, so the mount action's state changes.
• Dismounting by pressing the Summon Felsteed button directly (L1, no modifier)
  blocks that same MultiBar5Button12. Different input, same action: the error
  stays put.
• The same macro on LT+Z or LT+up throws nothing. That [mod:shift] branch is
  /petfollow and /petpassive--no /dismount, no state change, no error.

So, moving the action moves the error, changing the input path doesn't, and an
unmodified press throws just as readily as a chord. Modifiers only matter for
choosing which macro branch runs. That also fits the dispatcher behaviour; a
slot-scoped update fans out, and the button whose action changed runs
UpdateAction into the blocked SetAttribute.

Things I've now ruled out as the taint source:

• The SetAttributeNoHandler('action', i) loop in Model/Game/Actionbar.lua. I
  reported this above as "no effect", but that run was inconclusive - it watched a
  button on a bar CP also hides, so a second taint source could have masked it. Re-ran
  it watching MultiBar5Button12, which has no other CP touch-point, and it still
  errored. So it's genuinely not the source.
• Hotkey.lua's hotkey rendering, eliminated by the same test - it only reaches
  buttons GetActionButtons() discovers, and discovery goes through
  GetAttribute('action'), the attribute that test disables.
• ActionBarActionEventsFrame:UnregisterFrame(button) in hideActionButton. Button
  was still in that table at runtime afterward, error unchanged.
• Disabling the bars client-side. GetActionBarToggles() was already false for all
  four multibars the whole time.

That's every ConsolePort touch-point I can find on that button, so I suspect
ConsolePort may not be tainting these frames at all and is just on the execution
path when Blizzard's code trips over someone else's taint. The addon name has come
back as ConsolePort, ConsolePort_Bar and ConsolePort_World across the captures in
this thread.

Haven't done an addon bisect to confirm that but happy to if it'd be useful!

[FailMaven]

Correction to my last comment, plus what I think is the actual answer. I will go play and stop meddling after this, I swear.

I said ConsolePort probably wasn't the taint source but that was wrong. Bisecting to
only ConsolePort's 8 folders + !BugGrabber + BugSack still reproduces the issue, so CP plus a stock client is sufficient.

1.15.9 turned taintLog into a 4-level CVar, which logs the chain directly:

  Execution tainted by ConsolePort while reading field action
      ActionButton.lua:515  UpdatePressAndHoldAction()
  An action was blocked in combat because of taint from ConsolePort - ActionButton5:SetAttribute()
      ActionButton.lua:521  UpdatePressAndHoldAction()

Reading the tainted self.action at :515 taints execution and the protected
SetAttribute at :521 is blocked six lines later.

With all 8 ConsolePort folders loaded, every taint event in the file is attributed to core ConsolePort and not any of the other modules which are listed separately when they do taint. The reason it was so hard to pin down is that it isn't one vector. Capturing at level 1
with only ConsolePort loaded (586 lines, 75 blocked actions, no other addon named
in the file), three tainted fields lead to blocks:

• action, read at ActionButton.lua:515 in UpdatePressAndHoldAction, at :670 from
  UpdateShownButtons, and at :878 in UpdateSpellAlert
• the autocast shine list, read at TableUtil.lua:64 tDeleteItem() <-
  AutoCastOverlayManager:RemoveActiveShine() <- UpdateFlash() at Update():572
• popupDirection, read at Blizzard_Flyout/Flyout.lua:85 SetPopupDirection() <-
  UpdateFlyout() at Update():634

The autocast one fires at Update():572 before UpdatePressAndHoldAction at :593
so execution is already tainted regardless of the action field. That's why every
single fix I tried did nothing; I was looking for a single cause.

It's not confined to SetAttribute either: MultiBar5:UpdateShownButtons at
ActionBar.lua:204 had SetShown blocked on four MultiBar5 buttons which looks like
the same thing Gateswong hit.

One vector traces to a specific function. CPAPI.AutoCastStart in
ConsolePort/Utils/Wrapper.lua:646 calls AutoCastOverlay:ShowAutoCastEnabled(),
which is exactly the chain in the log:

  ShowAutoCastEnabled() -> AutoCastOverlayManager:RemoveActiveShine() -> tDeleteItem()

Callers are ConsolePort/Libs/Local/ActionButton.lua:59 and
ConsolePort_Bar/View/Pet/Petring.lua:175.

The reason it reaches Blizzard's buttons is that AutoCastOverlayManager is a
shared singleton with one global active-shine list. ConsolePort calls it on its
own widgets which seemingly taints that list and Blizzard's action buttons read the same
list during UpdateFlash(). So for this vector, ConsolePort isn't touching a
Blizzard button at all; the taint's leaking through a shared Blizzard object. That's
also why none of the "don't touch the button" fixes I tried made any difference.

Useful? AutoCastStart already prefers the legacy AutoCastShine_AutoCastStart
path when self.Shine exists, and only falls through to the shared manager
otherwise.

Happy to re-run taintLog against any change you want tested - I have characters on Classic Era (Hardcore) and
Retail available.

[zachspartofaday]

Confirmed that this can still occur on Retail 12.1.0 / ConsolePort 3.2.2 after #204. The remaining traces reached hidden Blizzard buttons through both ActionButton.lua:223 and ActionButton.lua:333, producing protected SetAttribute/SetShown failures and the downstream secret-value cooldown error.

I opened #217 with a follow-up that leaves Blizzard-owned buttons under the Blizzard update lifecycle and stores ConsolePort action lookup data outside their secure attributes. The previously affected setup reports no further Lua errors after applying it.