Spellflyout, SpellFlyout_Toggle, and taint

[Duugu]

Hello all

I'm stuck with a bad problem again.


My intention is to use Blizzards spellflyout feature, and to modify the layout of the flyout itself if the flyout buttons are shown (means: the expanding list of spells).

My first approach was this:

SecureHandler_OnLoad(_G["SpellFlyoutButton1"])
_G["SpellFlyoutButton1"]:WrapScript(_G["SpellFlyoutButton1"], "OnShow", [[
    local flyoutButtonSize = 29
    local rangeFromAButton = 5
    local t = string.sub(self:GetName(), 18)
    local degrees = self:GetParent():GetParent():GetAttribute("degree") * 3.14159265 / 180
    local nx = math.cos(degrees) - (((flyoutButtonSize * t) + rangeFromAButton) * math.sin(degrees))
    local ny = math.sin(degrees) + (((flyoutButtonSize * t) + rangeFromAButton) * math.cos(degrees))
    if self then
        self:ClearAllPoints()
        self:SetPoint("CENTER", self:GetParent():GetParent(), "CENTER", nx, ny) 
    end
]])

SpellFlyoutButton1 is the first of the expanding flyout buttons, and the solution works very well for the first button. The buttons new position is exactly as expected.

But ... there's a problem with the next buttons (a flyout can have a lot of buttons as you know). If the UI loads then only the first of the buttons (SpellFlyoutButton1) is created. All other buttons are created 'on the fly' if they are really needed.

Here's a part of the code for this from the Blizz interface file SpellFlyout.lua ("Createframe" at the bottom):

function SpellFlyout_Toggle(self, flyoutID, parent, direction, distance, isActionBar, specID, showFullTooltip)
    if (self:IsShown() and self:GetParent() == parent) then
        self:Hide();
        return;
    end
 
    local offSpec = specID and (specID ~= 0);
    
    -- Save previous parent to update at the end
    local oldParent = self:GetParent();
    local oldIsActionBar = self.isActionBar;
 
    local _, _, numSlots, isKnown = GetFlyoutInfo(flyoutID);
    local actionBar = parent:GetParent();
    self:SetParent(parent);
    self.isActionBar = isActionBar;
 
    -- Make sure this flyout is known or we are showing an offSpec flyout
    if ((not isKnown and not offSpec) or numSlots == 0) then
        self:Hide();
        return;
    end
    
    if (not direction) then
        direction = "UP";
    end
    
    -- Update all spell buttons for this flyout
    local prevButton = nil;
    local numButtons = 0;
    for i=1, numSlots do
        local spellID, overrideSpellID, isKnown, spellName, slotSpecID = GetFlyoutSlotInfo(flyoutID, i);
        local visible = true;
        
        -- Ignore Call Pet spells if there isn't a pet in that slot
        local petIndex, petName = GetCallPetSpellInfo(spellID);
        if (isActionBar and petIndex and (not petName or petName == "")) then
            visible = false;
        end
        
        if ( ((not offSpec or slotSpecID == 0) and visible and isKnown) or (offSpec and slotSpecID == specID) ) then
            local button = _G["SpellFlyoutButton"..numButtons+1];
            if (not button) then
                button = CreateFrame("CHECKBUTTON", "SpellFlyoutButton"..numButtons+1, SpellFlyout, "SpellFlyoutButtonTemplate");
            end

Now the problem: Obviously I can't set up my WrapScript before the button exists. So I have to listen if the player clicks on a flyout button for the first time (for example via hooking "SpellFlyout_Toggle" - see above) and to apply my script then. Unfortunately this could happen if the player is in combat. And if I then set the WrapScript everything is tainted. :/

The only possible way to work around this I can think of is to force the creation of all flyout buttons before the player enters combat.
My first approach to do this was calling SpellFlyout_Toggle() with a set of suitable arguments to initiate the frame creation. Which worked fine. I've managed it to call the function, the flyout was visible, I've wrapped my script to all of the flyout buttons and everything was great.
Until I entered combat and tried to open the flyout button ... then the interface stated my code was tainted (when executing the wrapped script). :/

That means, if I call SpellFlyout_Toggle() manually from unsecure code, and if the flyout frames are created by SpellFlyout_Toggle() then they are unsecure!? I'm not sure if I do understand why.

The second point is: how do I force the flyout button frames to get build from secure code (like inside a secure snippet) if I can't use SpellFlyout_Toggle() or reference the "Spellflyout" frame there?

I'm a bit lost to be honest. Any thoughts or words that could help to enlighten me are greatly appreciated. Thank you.

[Seerah]

You should modify them as they are created. Don't force them to be created.

[Duugu]

Originally Posted by Seerah You should modify them as they are created. Don't force them to be created.

But if I wait for them to be created it could be in combat. And if I apply the wrapscript in combat the frame is tainted. :/

[e]
Nevermind. Thanks for your reply.

I guess it's less time consuming to build my own flyout feature than trying to use the existing one.

[Duugu]

The bad thing is, my own flyout would mean I have to call GetFlyoutInfo(). Which means the flyout spells could be dragged to the button out of combat only. :/

The secure framework is such a mess.

[ravagernl]

Couldn't you store a reference to a secure frame inside an array in combat, and after combat, loop through that same array, do stuff and wipe it after that?

[Duugu]

Hm.

To implement my own flyout functionality I'll have to query and store the spells/spellids that a flyout (like the mage 'Portal') provides in when the player drags the flyout to my action button.

If the player then actually opens the flyout I'll have to set those spellids to all the pop out flyout buttons.

The only way to get the actual spellids of a flyout is GetFlyoutInfo()/GetFlyoutSlotInfo(). Which is unsecure and can't be directly called insided a secure snippet. I could call it via CallMethod() and unsecure code. But this will cause taint if I do this in combat.

So as far as I understand the whole thing is, that it is impossible to get the actual spell ids of a flyout in combat without tainting my frames.

Am I wrong?


[e]
I could pre-build a simple list of all flyout spells that are available to get around GetFlyoutInfo. Not smart but at least working.
Does anyone have an idea where to get a list of all available flyout spells?

[e2] Doh. Ok. New idea: I'll query all flyoutIDs up to ... whatever ... 1k and query and store all slots for flyoutIDs that exist on addon load. Then I'll pre-setup flyout action buttons for all of them on addon load. And in combat, if a player drags a flyout to an action button, I'll just have to move/show them. Don't know if this could work, but I'll try it tonight.
Also not smart, but could work.