Press and Hold Casting Not Working

[F-Lambda]

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

[Tuller]

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.

[Sythr4l]

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
}

[Tuller]

That's a different issue, and an indicator that something could be tainting the execution path

[akgis32]

can this be implemented, its a major disadvantage when using Dominios :(