Thread Tools Display Modes
02-14-18, 03:12 PM   #1
Nimhfree
A Frostmaul Preserver
AddOn Author - Click to view addons
Join Date: Aug 2006
Posts: 267
113x [ADDON_ACTION_BLOCKED] AddOn 'NimhfreeUI' tried to call the protected function '

When encountering bosses I get:

113x [ADDON_ACTION_BLOCKED] AddOn 'NimhfreeUI' tried to call the protected function 'Boss1TargetFrame:SetPoint()'

which I think is because of:

-- Move the target frame to the bottom left.
f=TargetFrame
f:SetMovable(1)
f:SetUserPlaced(true)
f:SetScale(.8)
f:ClearAllPoints()
f:SetPoint("LEFT",MultiBarRightButton7,"BOTTOMLEFT",0,100)

which is set up at the very start, so not in combat.

Anyone know how to do this properly?
  Reply With Quote
02-14-18, 03:31 PM   #2
Kakjens
A Cliff Giant
Join Date: Apr 2017
Posts: 75
https://www.wowinterface.com/forums/...ad.php?t=43637, http://www.wowinterface.com/forums/s...ead.php?t=1236 .
  Reply With Quote
02-14-18, 06:34 PM   #3
Nimhfree
A Frostmaul Preserver
AddOn Author - Click to view addons
Join Date: Aug 2006
Posts: 267
When you post those links are you trying to say there is not enough code present to understand what is happening?

The addon works. It changes the location, etc. of the default UI elements. It moves the target frame as indicated, as well as a lot of other frames. When in normal combat, no errors happen, and the target frame is where the addon moves it. However, when in a raid, for example, the indicated error occurs, and I attribute it to the target frame code. Here is code:

Code:
local _, release = GetBuildInfo()
release = tonumber(release)

--	Create a frame to receive events in which we have interest
local frame = CreateFrame("Frame")

--	Overwrite the default function used for "OnEvent"
frame:SetScript("OnEvent", function()

		--	Adjust the viewport to have a bottom area that is "empty".
		local f=WorldFrame
		f:SetUserPlaced(true)
		f:ClearAllPoints()
		f:SetPoint("TOPLEFT",0,0)
		f:SetPoint("BOTTOMRIGHT",0,115)

		--	Move the two right-side action bars to the middle, making them
		--	smaller and horizontal.
		for j,v in ipairs{"Left","Right"} do
			for i = 1,12 do
				local n="MultiBar"..v.."Button"
				local b,f=_G[n..i],1==i and StanceButton6 or n..i-1
				b:SetScale(.8)
				b:ClearAllPoints()
				b:SetPoint("LEFT",f,"RIGHT",i==1 and 68 or 6,i==1 and (j-1)*40 or 0)
			end
		end

		--	Move the objectives over to the right now that the action bars
		--	are no longer there.
		if release < 18505 then
			f=WatchFrame
		else
			f=ObjectiveTrackerBlocksFrame
		end
		f:SetMovable(1)
		f:SetUserPlaced(true)
		f:SetPoint("TOPRIGHT", MinimapCluster, "BOTTOMRIGHT", 0, 0)

		--	Hide griffons
		MainMenuBarLeftEndCap:Hide()
		MainMenuBarRightEndCap:Hide()

		--	Hide the player frame.
		PlayerFrame:Hide() 

		--	Move the target frame to the bottom left.
		f=TargetFrame
		f:SetMovable(1)
		f:SetUserPlaced(true)
		f:SetScale(.8)
		f:ClearAllPoints()
		f:SetPoint("LEFT",MultiBarRightButton7,"BOTTOMLEFT",0,100)

		--	Move the focus frame to above that
		f=FocusFrame
		f:SetMovable(1)
		f:SetUserPlaced(true)
		f:SetScale(.6)
		f:ClearAllPoints()
		f:SetPoint("TOPLEFT",TargetFrame,"TOPLEFT",-360,0)

		--	Make the pet buttons not be overridden by the action bars
		f=PetActionButton1
		f:SetMovable(1)
		f:SetUserPlaced(true)
		f:ClearAllPoints()
		f:SetPoint("BOTTOM",MultiBarRightButton1,"TOP",12,10)

		--	Move the buffs somewhere convenient
		f=BuffFrame
		f:SetMovable(1)
		f:SetUserPlaced(true)
		f:ClearAllPoints()
		f:SetPoint("TOPRIGHT",WorldFrame,"BOTTOMRIGHT",-290,-4)

		--	Clean up our frame since we no longer need it
		frame:UnregisterEvent("PLAYER_ENTERING_WORLD")
		frame:SetScript("OnUpdate", nil)
		frame = nil

	end)

--	Register for interesting events
frame:RegisterEvent("PLAYER_ENTERING_WORLD")
  Reply With Quote
02-14-18, 09:59 PM   #4
Nimhfree
A Frostmaul Preserver
AddOn Author - Click to view addons
Join Date: Aug 2006
Posts: 267
I just ran an experiment with the addon having commented out the moving of the TargetFrame and the FocusFrame, as well as editing the layout-local.txt file to ensure any entries for those frames were removed.

For most of the fights everything went well. However, on one of them (the second) in the series, the error appeared. Therefore, I cannot hazard a guess as to what is really happening.
  Reply With Quote
02-14-18, 11:32 PM   #5
Tosaido
A Fallenroot Satyr
 
Tosaido's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2015
Posts: 23
Hi, it's been awhile since I've done anything with unit frames but wouldn't Boss1TargetFrame be the target of the first boss frame and not your target?

anyway, these frames use a secure frame template which means that when you're in combat and you change any of the frames attributes, including things like :Show, :Hide and :Setpoint you will cause taint for that frame and anything related to it, which is very bad and should be avoided.

It's up to the author to prevent this, by simply checking InCombatLockdown() before changing a secure frames attributes
  Reply With Quote
02-15-18, 05:02 AM   #6
MunkDev
A Scalebane Royal Guard
 
MunkDev's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 431
Lua Code:
  1. if release < 18505 then
  2.     f=WatchFrame
  3. else
  4.     f=ObjectiveTrackerBlocksFrame
  5. end

No private servers please.
Nothing in the code you posted will spread taint. Unless there's more to it than what you care to reveal here, this is not the culprit of your error.
__________________
  Reply With Quote
02-15-18, 08:22 AM   #7
Nimhfree
A Frostmaul Preserver
AddOn Author - Click to view addons
Join Date: Aug 2006
Posts: 267
I didn't think there was any taint. I was just so confused, and with my version that does not change the TargetFrame it shows that I am not doing the taint here. Perhaps the taint is from something else but my addon gets the blame.

It is not a private server, but when I wrote the code I had to handle both live and PTR. I just keep the code in place as a reminder to keep handling version issues, plus a reminder of how a problem was solved. You will see most of my addons are like this. I even left the old architecture in place for getting completed quests from the server, while transforming it for the new way Blizzard does things.
  Reply With Quote
02-15-18, 11:11 AM   #8
MunkDev
A Scalebane Royal Guard
 
MunkDev's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 431
It's very likely your addon is still the cause, unless the code you provided is all there is. The tainting addon will be correctly listed as the offender in most cases, and I'm guessing the stack trace that you didn't include will say this error originated from UIParent.lua.

There are a couple of different things that can cause this:
1. The terrible, but unfortunately common, practice to use no-op functions to replace functions on widgets to nullify some change they don't want in their UI. E.g.
Lua Code:
  1. PlayerFrame.SetPoint = function() end
Don't do this, and if you have done this, use this approach instead.

2. Calling Lua-implemented functions that bears taint with it to a table or local values in the default UI. E.g.
Lua Code:
  1. AutoQuestPopupTracker_AddPopUp(questID, popUpType) -- implemented in Lua, not safe to call
  2. AddAutoQuestPopUp(questID, popUpType) -- unprotected API function, safe to call

3. A combination of the above, where you replace an API function to gate or nullify the changes it attempts to make. If the function is called from a code scope that eventually does something secure, the taint spread is revealed.

If you're not guilty of this, your addon is not the cause. Like I already said, the code you posted has nothing to do with the error you're getting. Just because it happens to be Boss1TargetFrame doesn't mean it has anything to do with you moving the regular TargetFrame around. They're completely unrelated.
__________________

Last edited by MunkDev : 02-15-18 at 11:16 AM.
  Reply With Quote
02-15-18, 03:07 PM   #9
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,290
You can't anchor stuff to the MultiBarRightButton7 not to the whole MultiBarRight, since the multibar is protected so every time the Boss frames appears that pushes the MultiBarActionBars to the left in combat (if there is enough Boss frames to push it (but the SetPoint update runs even with 1 visible Boss frame, or even when the game just decides to run a full frame update)), which cause taint all across every anchored and child objects. The root of the issue is that the TargetFrame gets hidden and shown in combat, since you kinda want to target and untarget units while in combat too.

This is the same fiasco that happens with the MiniMap, since Arena frames are anchored to the MiniMap, you can't so anything protected with the MiniMap in combat, as long as the protected Arena frames are anchored to it.

Last edited by Resike : 02-15-18 at 03:11 PM.
  Reply With Quote
02-15-18, 07:36 PM   #10
MunkDev
A Scalebane Royal Guard
 
MunkDev's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 431
Originally Posted by Resike View Post
You can't anchor stuff to the MultiBarRightButton7 not to the whole MultiBarRight, since the multibar is protected so every time the Boss frames appears that pushes the MultiBarActionBars to the left in combat (if there is enough Boss frames to push it (but the SetPoint update runs even with 1 visible Boss frame, or even when the game just decides to run a full frame update)), which cause taint all across every anchored and child objects. The root of the issue is that the TargetFrame gets hidden and shown in combat, since you kinda want to target and untarget units while in combat too.
Why wouldn't you be able to? As long as the code that moves it is signed and untainted, there are no issues with protected frames anchoring to each other.
Setting a point for a frame out of combat doesn't spread taint.

To prove my point, I created a secure action button, anchored it to LootFrame, which is completely unprotected and moved around in combat to follow the mouse cursor.
The LootFrame code, however, is not tainted and is moved around by signed Blizzard code. Therefore, no problem.

Try it yourself:
Lua Code:
  1. local f = CreateFrame('Button', 'JustASecureButton', LootFrame, 'SecureActionButtonTemplate, ActionButtonTemplate')
  2. f:SetPoint('TOPRIGHT', LootFrame, 'BOTTOMLEFT')
  3. f:SetAttribute('type', 'action')
  4. f:SetAttribute('action', 6)
  5. f.icon:SetTexture(GetActionTexture(6))

There seems to be a lot of misconceptions about taint floating around.
__________________

Last edited by MunkDev : 02-15-18 at 07:56 PM.
  Reply With Quote
02-15-18, 10:13 PM   #11
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,290
Originally Posted by MunkDev View Post
Why wouldn't you be able to? As long as the code that moves it is signed and untainted, there are no issues with protected frames anchoring to each other.
Setting a point for a frame out of combat doesn't spread taint.

To prove my point, I created a secure action button, anchored it to LootFrame, which is completely unprotected and moved around in combat to follow the mouse cursor.
The LootFrame code, however, is not tainted and is moved around by signed Blizzard code. Therefore, no problem.

Try it yourself:
Lua Code:
  1. local f = CreateFrame('Button', 'JustASecureButton', LootFrame, 'SecureActionButtonTemplate, ActionButtonTemplate')
  2. f:SetPoint('TOPRIGHT', LootFrame, 'BOTTOMLEFT')
  3. f:SetAttribute('type', 'action')
  4. f:SetAttribute('action', 6)
  5. f.icon:SetTexture(GetActionTexture(6))

There seems to be a lot of misconceptions about taint floating around.
First the two things are completely different. The guy here SetPoints a protected frame to another protected frame, which gets moved in combat by Blizzard, without restrictions, and without any secure code, just because Blizzard can do that. And when that happens that code will get blamed whoever called the initial SetPoint, it does not matter if that SetPoint was called securely or not.

Here is the code where the Blizzard code could decide to move the MultiBars at any time:

https://github.com/Resike/BlizzardIn...ua#L2709-L2713

You pull a boss, combat locks down, boss frames show up (or not), MultiBarLeft and MultiBarRight gets pushed to the left on the x axis (or not) TargetFrame (protected) are anchored to the MultiBarRight, so basically you try to move a protected frame in combat. And bang you get blamed for the whole taint, even tho you set your initial position seucrely and did't tried to move anything in combat.

Last edited by Resike : 02-15-18 at 10:19 PM.
  Reply With Quote
02-15-18, 10:31 PM   #12
Nimhfree
A Frostmaul Preserver
AddOn Author - Click to view addons
Join Date: Aug 2006
Posts: 267
So does this mean I am not allowed to anchor anything to the MultiBarButtons at all? I will change how they are anchored and test to see what happens.
  Reply With Quote
02-15-18, 11:27 PM   #13
Nimhfree
A Frostmaul Preserver
AddOn Author - Click to view addons
Join Date: Aug 2006
Posts: 267
It turns out that moving the quest frame also caused problems when the boss frame appears. So I think I have it working now, but cannot move the quest frame.

Does anyone know if it is possible to move these frames that get moved by Blizzard code when the boss frames appear? I had thought the code I was using would work, but it seems not.
  Reply With Quote
02-15-18, 11:31 PM   #14
MunkDev
A Scalebane Royal Guard
 
MunkDev's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 431
Originally Posted by Resike View Post
First the two things are completely different. The guy here SetPoints a protected frame to another protected frame, which gets moved in combat by Blizzard, without restrictions, and without any secure code, just because Blizzard can do that. And when that happens that code will get blamed whoever called the initial SetPoint, it does not matter if that SetPoint was called securely or not.
They are not different; Blizzard code does not adhere to combat lockdown, regardless if it's moving protected or unprotected frames, which is why I posted that video as proof. Creating a secure child frame will also make the parent inherently secure, so if what you're saying is true, LootFrame would go bonkers with the code I posted, but it doesn't. Using SetPoint out of combat does not spread taint and your addon will not get blamed for anything if you do.

Please, Nimhfree, post your entire code for the whole addon if you haven't already. I'm 99% sure your problems come from somewhere else.
__________________

Last edited by MunkDev : 02-15-18 at 11:34 PM.
  Reply With Quote
02-16-18, 06:47 AM   #15
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,290
Originally Posted by MunkDev View Post
They are not different; Blizzard code does not adhere to combat lockdown, regardless if it's moving protected or unprotected frames, which is why I posted that video as proof. Creating a secure child frame will also make the parent inherently secure, so if what you're saying is true, LootFrame would go bonkers with the code I posted, but it doesn't. Using SetPoint out of combat does not spread taint and your addon will not get blamed for anything if you do.

Please, Nimhfree, post your entire code for the whole addon if you haven't already. I'm 99% sure your problems come from somewhere else.
I think you oversimplify things, they way it should work and the way it works is completely different when we talk about taint. The default dropdown templates and their methods should not taint addons but they still do (mostly because of the reused objects), the mapframe should not go bonkers when opened in combat and blame pointless taint on addons even when not a single addon even touched the mapframe, but it does. The CompactRaidFrameX:ClearAllPoints() taint should never happen with disabled default raid frames but it still does. I'm not claiming that this is the way things currently work in the live servers, just sharing my experience from the past which might come handy since the guy plays on a private server (somewhere from endBC to MOP).

Taint are specially hard to track down, and works differently for different frames, and other enabled addons also play a big role.
  Reply With Quote

WoWInterface » AddOns, Compilations, Macros » AddOn Help/Support » 113x [ADDON_ACTION_BLOCKED] AddOn 'NimhfreeUI' tried to call the protected function '

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off