Press and Hold Casting Not Working
F-Lambda opened this issue ยท 4 comments
Press and hold casting does not function with Dominos active. Deactivating Dominos causes it to work again.
Addon Version
10.2.18-retail
World of Warcraft Version
Retail 10.2.5 (53262) (Release x64)
Feb 7 2024
Dominos can only ever implement this for a subset of action buttons (specifically Dominos action bars 1, 3, 4, 5 6, 12, 13, and 14). I've currently disabled this behavior, as it was one of the culprits of action buttons suddenly not working after switching zones/etc. I'll try re-implementing it to see if the other taint mitigations I have in place allow it to function properly now, and we need to hope that Blizzard fixes the issue preventing it from working for all action buttons in the next expansion.
How the Standard Interface Implements Support
Blizzard action buttons don't use the same execution path for keybindings as addons need to. One part of that path sets a flag that is required for press and hold casting to function.
-- ActionButton.lua
function TryUseActionButton(self, checkingFromDown)
local isKeyPress = true;
local isSecureAction = true;
local usedActionButton = SecureActionButton_OnClick(self, "LeftButton", checkingFromDown, isKeyPress, isSecureAction);
if usedActionButton then
if GetNewActionHighlightMark(self.action) then
ClearNewActionHighlight(self.action);
self:UpdateHighlightMark();
end
end
self:UpdateState();
end
-- SecureTemplates.lua
function SecureActionButton_OnClick(self, inputButton, down, isKeyPress, isSecureAction)
-- Why are we adding extra arguments, 'isKeyPress' and 'isSecureAction', to an _OnClick handler?
-- We want to prevent mouse actions from triggering press-and-hold behavior for now, but we do want to allow AddOns
-- to function as they did before. This is a problem since there's no difference between an AddOn's key press behavior
-- and mouse click behavior. So if we don't know where this is coming from, it's from an AddOn and should be treated as
-- a key press not a mouse press for 'useOnKeyDown' purposes.
local isSecureMousePress = not isKeyPress and isSecureAction;
local pressAndHoldAction = SecureButton_GetAttribute(self, "pressAndHoldAction");
local useOnKeyDown = not isSecureMousePress and (GetCVarBool("ActionButtonUseKeyDown") or pressAndHoldAction);
local clickAction = (down and useOnKeyDown) or (not down and not useOnKeyDown);
local releasePressAndHoldAction = (not down) and (pressAndHoldAction or GetCVarBool("ActionButtonUseKeyHeldSpell"));
if clickAction then
-- Only treat a key down action as a key press. Treating key up actions as a key press will result in the held
-- spell being cast indefinitely since there's no release to stop it.
local treatAsKeyPress = down and isKeyPress;
OnActionButtonClick(self, inputButton, down, treatAsKeyPress);
return true;
elseif releasePressAndHoldAction then
OnActionButtonPressAndHoldRelease(self, inputButton);
return true;
end
return false;
end
SecureActionButton_OnClick
only ever triggers press and hold casting if it thinks it is being called by a key press action, and the only way to make that be the case is to use TryUseActionButton
. Addons currently cannot do this (as documented by Blizzard in SecureActionButton_OnClick.
Workarounds
Knowing this, I was able to still trigger this behavior by essentially letting the stock UI handle key press logic for any of the standard action buttons (Dominos action bars 1, 3, 4, 5 6, 12, 13, and 14) and making it simply appear as if the Dominos action button was pressed.
There's a major drawback to this approach, however. The Blizzard UI in dragon flight is particularly fragile with respect to tainting issues. This was the leading culprit that lead to the persistent "action buttons no longer working when switching into a new zone/dungeon" issue that Dominos had in the past. This is why I removed press and hold casting support starting with 10.2.5.
I think this is related, apologize if it's not. I received this error despite having press and hold turned off.
1x [ADDON_ACTION_BLOCKED] AddOn 'Dominos' tried to call the protected function 'MultiBarBottomRightActionButton1:SetAttribute()'.
[string "@!BugGrabber/BugGrabber.lua"]:485: in function <!BugGrabber/BugGrabber.lua:485>
[string "=[C]"]: in function SetAttribute' [string "@FrameXML/ActionButton.lua"]:485: in function
UpdatePressAndHoldAction'
[string "@FrameXML/ActionButton.lua"]:551: in function Update' [string "@FrameXML/ActionButton.lua"]:503: in function
UpdateAction'
[string "@FrameXML/ActionButton.lua"]:981: in function `OnEvent'
[string "@FrameXML/ActionButton.lua"]:207: in function <FrameXML/ActionButton.lua:204>
Locals:
_ = Frame {
RegisterEvent = defined @!BugGrabber/BugGrabber.lua:491
0 =
UnregisterEvent = defined @!BugGrabber/BugGrabber.lua:491
SetScript = defined @!BugGrabber/BugGrabber.lua:491
}
event = "ADDON_ACTION_BLOCKED"
events =
ADDON_ACTION_BLOCKED = defined @!BugGrabber/BugGrabber.lua:557
ADDON_ACTION_FORBIDDEN = defined @!BugGrabber/BugGrabber.lua:557
PLAYER_LOGIN = defined @!BugGrabber/BugGrabber.lua:551
LUA_WARNING = defined @!BugGrabber/BugGrabber.lua:566
ADDON_LOADED = defined @!BugGrabber/BugGrabber.lua:511
}
That's a different issue, and an indicator that something could be tainting the execution path