CreateFrame() in combat taint

[Resike]

In the past weeks i have been struggling to fix this this issue with a raid frame addon, and i tried everything but nothing really give a proper fix.

It mostly happens when someone joins in the raid group while the player is in combat:

2/20 00:53:10.420  CreateFrame()
2/20 00:53:10.420  An action was blocked in combat because of taint from ZPerl_RaidFrames - 
2/20 00:53:10.420      CreateFrame()
2/20 00:53:10.420      Interface\FrameXML\SecureGroupHeaders.lua:164 configureChildren()
2/20 00:53:10.420      Interface\FrameXML\SecureGroupHeaders.lua:488 SecureGroupHeader_Update()
2/20 00:53:10.420      Interface\FrameXML\SecureGroupHeaders.lua:62

I have tried to play with the own "self:SetAttribute("child"..x, self)" creation, but i'm not sure how and when to do it.
If someone could point me in the right direction i would really appreciate it.

Code:
https://github.com/Resike/Z-Perl/tre...erl_RaidFrames

[SDPhantom]

The problem is you can't create secure frames or modify their attributes while in combat. I don't know a lot about the SecureHeaders, so I'm at a loss for suggestions.

[Phanx]

I have neither the time nor the inclination to look through 10000000 lines of XPerl/ZPerl code to find the relevant sections, but in general, you cannot create, show, hide, move, resize, or change attributes on secure frames while in combat.

If you are using secure headers, you need to set them up with the proper attributes before entering combat, and you should never need to set attributes telling a header which frames are its children. If your header isn't automatically managing its own children (the unit frames) you didn't set up the header correctly. If you want help figuring it out, post (a link to) the actual section of the actual file where you create the header.

If you are creating individual frames, you need to create, size, and place them all before entering combat. You can't create unit frames "on demand" like you can with non-secure frames.

In either case, if anything happens in combat that would trigger layout changes, you have to wait until combat ends to apply those changes.

[Resike]

Originally Posted by Phanx I have neither the time nor the inclination to look through 10000000 lines of XPerl/ZPerl code to find the relevant sections, but in general, you cannot create, show, hide, move, resize, or change attributes on secure frames while in combat. If you are using secure headers, you need to set them up with the proper attributes before entering combat, and you should never need to set attributes telling a header which frames are its children. If your header isn't automatically managing its own children (the unit frames) you didn't set up the header correctly. If you want help figuring it out, post (a link to) the actual section of the actual file where you create the header. If you are creating individual frames, you need to create, size, and place them all before entering combat. You can't create unit frames "on demand" like you can with non-secure frames. In either case, if anything happens in combat that would trigger layout changes, you have to wait until combat ends to apply those changes.

Everything raid releated stuff is in the 2 files i linked: ZPerl_Raid.lua, ZPerl_Raid.xml.
The addon is using secure headers, for both party and raid frames. The party handling works perfectly, only the raid one are faulty.

The secure header is created in the xml:

https://github.com/Resike/Z-Perl/blo..._Raid.xml#L280

Inherited to 11 raid groups:

https://github.com/Resike/Z-Perl/blo..._Raid.xml#L460

The secure unit button for one player is here:

https://github.com/Resike/Z-Perl/blo...l_Raid.xml#L47

[Duugu]

First of all - are you sure that this is a zperl problem? Does it happen with all other addons deactivated? It's hard to believe that a sophisticated addon like xperl (suddenly?) creates secure frames in combat. Do you have modified stuff within the relevant parts in your fork?

[Resike]

Originally Posted by Duugu First of all - are you sure that this is a zperl problem? Does it happen with all other addons deactivated? It's hard to believe that a sophisticated addon like xperl (suddenly?) creates secure frames in combat. Do you have modified stuff within the relevant parts in your fork?

It's 100% caused by the addon, but it's not really the addon's fault. This bug is in the addon since year, just noone take the time to eliminate it.
The fun part this is even happening with the default raid frames too, just silently.

You can read more about it here:

http://us.battle.net/wow/en/forum/topic/8691469393

[Phanx]

This can't be done if the frame is loading in combat:
https://github.com/Resike/Z-Perl/blo..._Raid.lua#L593

This is not a safe way of showing a dropdown menu:
https://github.com/Resike/Z-Perl/blo...Perl.lua#L2375
You're already setting a "togglemenu" action, so I don't know why you're manually repositioning DropDownList1, but given the fragility of the dropdown menu system, if you do this in combat you'll probably break all protected dropdown entries (set focus, leave battleground queue, etc.) and taint who knows what else. If you want to show a dropdown menu, do it right.

I also don't really understand why you're creating a unit button within a unit button:
https://github.com/Resike/Z-Perl/blo...l_Raid.xml#L47
https://github.com/Resike/Z-Perl/blo...l_Raid.xml#L68
...but it's probably not helping anything.

There's also a vast array of problems with endless tables being created repeatedly for no apparent reason (why return a table containing values instead of just returning the values?!) but that's not related to the error you're getting, just a generalized (and rather large) efficiency problem that can be considered later.

Other than that, this codebase is extremely convoluted, with functions being called from various other files everywhere, and I just don't have the interest level to keep following winding chains of function calls around, but if none of the above are causing the specific error you're getting, it shouldn't really be too difficult to track it down. Move any secure OnLoad stuff (like registering for clicks or setting attributes) into an initialConfigFunction snippet (see oUF for an example) and/or just go through the entire codebase and make sure you're checking for combat lockdown first every time you do anything with a secure frame.

It may also be helpful to enable taint logging (/console taintLog 2) and check the taint.log folder in your WoW/Logs folder. Depending on your computer, it may be written to pretty much in real-time, or it may not get written until you log out (though it may be overwritten with a blank file if you reload the UI instead of logging out).

[Phanx]

Originally Posted by Resike The fun part this is even happening with the default raid frames too, just silently.

Oh, that bug. Grid added a workaround for that (or something like it) back in 2010; this post may be relevant to your interests:
http://forums.wowace.com/showpost.ph...postcount=3163

[Duugu]

It's 100% caused by the addon

Well, then I would say you're in trouble as it could be everything. Player frames, pet frames, buff arames, MTs ... I even saw some action buttons (!?).

Digging around a bit (it A LOT of code) my first guess would be https://github.com/Resike/Z-Perl/blo..._Raid.lua#L590
You could try to mask everything in "XPerl_Raid_Single_OnLoad(self)" via "if (InCombatLockdown()) then ..." to see what happens.

[Duugu]

Phanx No Life!

[Resike]

Originally Posted by Phanx Oh, that bug. Grid added a workaround for that (or something like it) back in 2010; this post may be relevant to your interests: http://forums.wowace.com/showpost.ph...postcount=3163

I know the codebase of XPerl/ZPerl is beyond terribad and very old, currrently trying to patch it up a bit, to keep the mod alive.

I added this code, and it seems like the problem disappeared. Need more testing tho, but if it's gonna work, i'll buy you a cat. Thanks for your help.

[Phanx]

Originally Posted by Duugu

I know, I finally made it! I have transcended the material plane and become one with the Internet!

Originally Posted by Resike I added this code, and it seems like the problem disappeared. Need more testing tho, but if it's gonna work, i'll buy you a cat.

If you run into any issues, you may want to compare that code with what's currently in Grid, as there are some minor changes, but I don't remember why those changes were made, or even if I were the one to make them...