tullamods / Dominos

A main actionbar replacement
https://tullamods.com/dominos
BSD 3-Clause "New" or "Revised" License
78 stars 27 forks source link

Press and Hold Casting Not Working #835

Open F-Lambda opened 7 months ago

F-Lambda commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 functionUpdatePressAndHoldAction' [string "@FrameXML/ActionButton.lua"]:551: in function Update' [string "@FrameXML/ActionButton.lua"]:503: in functionUpdateAction' [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 commented 7 months ago

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

akgis32 commented 2 months ago

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