Chat class colours and oUF taint

[Haleth]

Hello.

I use a custom class colour table in my UI to avoid overwriting RAID_CLASS_COLORS and causing taint, thanks to a tip from p3lim. However, to get these new colours on player names in the chat frame, the most common method seems to be to simply overwrite the function GetColoredName. This causes taint when someone enters a party or raid while the player is in combat, though, so I'm wondering if there's a better way to do it (tried using hooksecurefunc, doesn't work).

Also, I'm getting a taint error from oUF every time someone joins a party or raid while the player is in combat, and the specific oUF party/raid frame for that player won't spawn properly. I'm just wondering if anyone else is getting this, before I report it as a bug on Haste's github, unless it's a Blizzard error.

Edit: taint log for chat problem:

11/18 18:54:40.961  Global variable GetColoredName tainted by !FreeUI - Interface\AddOns\!FreeUI\scripts\chat.lua:257
11/18 18:54:40.961  Execution tainted by !FreeUI while reading GetColoredName - Interface\FrameXML\ChatFrame.lua:2744 ChatFrame_MessageEventHandler()
11/18 18:54:40.961      Interface\FrameXML\ChatFrame.lua:2550 ChatFrame_OnEvent()
11/18 18:54:40.961      ChatFrame1:OnEvent()

oUF:

11/18 17:04:57.064  An action was blocked in combat because of taint from !FreeUI - oUF_FreePartyRaidUnitButton3:SetSize()
11/18 17:04:57.064      Interface\AddOns\!FreeUI\scripts\unitframes.lua:903 styleFunc()
11/18 17:04:57.064      Interface\AddOns\!FreeUI\oUF\ouf.lua:418
11/18 17:04:57.064      Interface\FrameXML\RestrictedFrames.lua:721
11/18 17:04:57.064      securecall()
11/18 17:04:57.064      Interface\FrameXML\RestrictedFrames.lua:740 CallMethod()
11/18 17:04:57.064      		local header = self:GetParent()
		local frames = table.new()
		table.insert(frames, self)
		self:GetChildList(frames)
		for i=1, #frames do
			local frame = frames[i]
			local unit
			-- There's no need to do anything on frames with onlyProcessChildren
			if(not frame:GetAttribute'oUF-onlyProcessChildren') then
				RegisterUnitWatch(frame)

				-- Attempt to guess what the header is set to spawn.
				if(header:GetAttribute'showRaid') then
					unit = 'raid'
				elseif(header:GetAttribute'showParty') then
					unit = 'party'
				end

				local headerType = header:GetAttribute'oUF-headerType'
				local suffix = frame:GetAttribute'unitsuffix'
				if(unit and suffix) then
					if(headerType == 'pet' and suffix == 'target') then
						unit = unit .. headerType .. suffix
					else
						unit = unit .. suffix
					end
				elseif(unit and headerType == 'pet') then
					unit = unit .. headerType
				end

				frame:SetAttribute('*type1', 'target')
				frame:SetAttribute('*type2', 'menu')
				frame:SetAttribute('togg
11/18 17:04:57.064      pcall()
11/18 17:04:57.064      Interface\FrameXML\RestrictedExecution.lua:441 CallRestrictedClosure()
11/18 17:04:57.064      Interface\FrameXML\SecureGroupHeaders.lua:108 SetupUnitButtonConfiguration()
11/18 17:04:57.064      Interface\FrameXML\SecureGroupHeaders.lua:158 configureChildren()
11/18 17:04:57.064      Interface\FrameXML\SecureGroupHeaders.lua:458 SecureGroupHeader_Update()
11/18 17:04:57.064      Interface\FrameXML\SecureGroupHeaders.lua:48

[brotherhobbes]

i don't know!

have you checked out other addons like: http://www.wowinterface.com/download...assColors.html

[Haleth]

Overwriting the Blizzard function is how that addon does it unfortunately.

Edit: the oUF taint error is probably due to me using SetSize on the party frames rather than using initialConfigFunction.

Edit2: Eventually managed to figure out the chat coloring too.

[Torhal]

Originally Posted by Haleth Overwriting the Blizzard function is how that addon does it unfortunately. <snip>

No, it doesn't. It's specifically designed to not taint RAID_CLASS_COLORS by not overwriting it, and supplying its own table. Other AddOns can support it by checking for CUSTOM_CLASS_COLORS, and using it if it exists or RAID_CLASS_COLORS if it does not.

[Dawn]

What Torhal says, Class Colors is the probably the best way to go if you want to avoid taint and still be able to change class colors.

For example like this

local _, class = UnitClass('player')
local color = CUSTOM_CLASS_COLORS and CUSTOM_CLASS_COLORS[class] or RAID_CLASS_COLORS[class]			
whatever:SetColor(color.r, color.g, color.b)

This will also use RAID_CLASS_COLORS, if CUSTOM_CLASS_COLORS through Class Colors are unavailable.

[Dridzt]

Originally Posted by Torhal No, it doesn't. It's specifically designed to not taint RAID_CLASS_COLORS by not overwriting it, and supplying its own table. Other AddOns can support it by checking for CUSTOM_CLASS_COLORS, and using it if it exists or RAID_CLASS_COLORS if it does not.

It very much does so.
This isn't to say it causes taint but ClassColors DOES overwrite GetColoredName() in ClassColorsBlizz.lua.

[Phanx]

!ClassColors does currently overwrite GetColoredName. While this does cause taint, it does NOT taint any secure code, unless your addon is trying to call it in secure code. You can verify this yourself by looking at Blizzard's UI source code; the GetColoredName function is called only in one place (FrameXML\ChatFrame.lua, line 2724), inside the same file that defines it (FrameXML\ChatFrame.lua, line 2671).

It would be possible to color chat names without overwriting GetColoredName, and I'll probably do it at some point, but I'm lazy, and overwriting it doesn't break any parts of the default UI.

[Haleth]

That's what I meant. I managed to get it working without taint eventually. Overwriting GetColoredName only causes taint if you, well, change it too much from the original.

[Dawn]

Since we are talking about colors:
Would you consider adding an option to change Faction colors to your Class Colors addon, Phanx?

[Haleth]

Slight update on the problem, overwriting GetColoredName does seem to cause taint.

11/21 20:53:33.484  Global variable GetColoredName tainted by !FreeUI - Interface\AddOns\!FreeUI\scripts\chat.lua:258
11/21 20:53:33.484  Execution tainted by !FreeUI while reading GetColoredName - Interface\FrameXML\ChatFrame.lua:2744 ChatFrame_MessageEventHandler()
11/21 20:53:33.484      Interface\FrameXML\ChatFrame.lua:2550 ChatFrame_OnEvent()
11/21 20:53:33.484      ChatFrame10:OnEvent()
11/21 20:53:33.484  An action was blocked because of taint from !FreeUI - CancelUnitBuff()
11/21 20:53:33.484      Interface\FrameXML\BuffFrame.lua:280 BuffButton_OnClick()
11/21 20:53:33.484      BuffButton2:OnClick()

function GetColoredName(event, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12)
	local chatType = strsub(event, 10);
	if ( strsub(chatType, 1, 7) == "WHISPER" ) then
		chatType = "WHISPER";
	end
	if ( strsub(chatType, 1, 7) == "CHANNEL" ) then
		chatType = "CHANNEL"..arg8;
	end
	local info = ChatTypeInfo[chatType];
	
	if ( info and info.colorNameByClass and arg12 ~= "" ) then
		local localizedClass, englishClass, localizedRace, englishRace, sex = GetPlayerInfoByGUID(arg12)
		
		if ( englishClass ) then
			local classColorTable = FreeUI.classcolors[englishClass];
			if ( not classColorTable ) then
				return arg2;
			end
			return string.format("\124cff%.2x%.2x%.2x", classColorTable.r*255, classColorTable.g*255, classColorTable.b*255)..arg2.."\124r"
		end
	end
	
	return arg2;
end

FreeUI.classcolors = {
	["DEATHKNIGHT"] = {r = 0.77, g = 0.12, b = 0.23},
	["DRUID"] = {r = 1, g = 0.49, b = 0.04},
	["HUNTER"] = {r = 0.58, g = 0.86, b = 0.49},
	["MAGE"] = {r = 0, g = 0.76, b = 1},
	["PALADIN"] = {r = 1, g = 0.22, b = 0.52},
	["PRIEST"] = {r = 0.8, g = 0.87, b = .9},
	["ROGUE"] = {r = 1, g = 0.91, b = 0.2},
	["SHAMAN"] = {r = 0, g = 0.6, b = 0.6},
	["WARLOCK"] = {r = 0.6, g = 0.47, b = 0.85},
	["WARRIOR"] = {r = 0.9, g = 0.65, b = 0.45},
}

How would I go about doing this properly without overwriting? I tried a couple of things already but they won't work.

[Phanx]

Originally Posted by Haleth That's what I meant. I managed to get it working without taint eventually. Overwriting GetColoredName only causes taint if you, well, change it too much from the original.

That isn't how taint works. Overwriting a Blizzard-defined global causes taint, period.

Originally Posted by Dawn Since we are talking about colors: Would you consider adding an option to change Faction colors to your Class Colors addon, Phanx?

As has been asked and answered at least once on the addon's comment page, no, I have no plans to add options for power colors, faction colors, etc. Changing those colors does not break any part of the default UI that I'm aware of, so you can (and should) just modify the Blizzard-defined tables for them directly.

Originally Posted by Haleth Slight update on the problem, overwriting GetColoredName does seem to cause taint.

Of course it does.

It doesn't, however, break right-click buff cancelling. I just logged in with no addons enabled except for a "sandbox" addon that contained only the code from your last post (plus a FreeUI = { } at the top), and was able to right-click cancel buffs just fine.

At login:

11/21 21:06:37.890  Global variable GetColoredName tainted by PhanxMod - Interface\AddOns\PhanxMod\Sandbox.lua:14

When sending a whisper to myself:

11/21 21:06:43.656  Execution tainted by PhanxMod while reading GetColoredName - Interface\FrameXML\ChatFrame.lua:2744 ChatFrame_MessageEventHandler()
11/21 21:06:43.656      Interface\FrameXML\ChatFrame.lua:2550 ChatFrame_OnEvent()
11/21 21:06:43.656      ChatFrame1:OnEvent()
11/21 21:06:43.765  Execution tainted by PhanxMod while reading GetColoredName - Interface\FrameXML\ChatFrame.lua:2744 ChatFrame_MessageEventHandler()
11/21 21:06:43.765      Interface\FrameXML\ChatFrame.lua:2550 ChatFrame_OnEvent()
11/21 21:06:43.765      ChatFrame1:OnEvent()

There weren't any messages related to the buff frame, or any actions blocked. Most likely, something else in your addon is tainting another variable that's causing buff right-clicking to fail.

Originally Posted by Haleth How would I go about doing this properly without overwriting?

Well, there's simply no way to do it without overwriting something. You can either overwrite GetColoredName, or you can overwrite FCF_GetTemporaryWindow and each chat frame's AddMessage method:

local colorMap = { }

for class, old in pairs(RAID_CLASS_COLORS) do
	local new = CUSTOM_CLASS_COLORS[class]
	colorMap[("\124cff%02x%02x%02x"):format(old.r * 255, old.g * 255, old.b * 255)] = ("\124cff%02x%02x%02x"):format(new.r * 255, new.g * 255, new.b * 255)
end

local hooks = { }

local AddMessage = function(frame, message, ...)
	if type(message) == "string" then
		for old, new in pairs(colorMap) do
			message = message:replace(old, new)
		end
	end
	return hooks[frame](frame, message, ...)
end

for i = 1, NUM_CHAT_WINDOWS do
	local frame = _G["ChatFrame" .. i]
	hooks[frame] = frame.AddMessage
	frame.AddMessage = AddMessage
end

hooks.FCF_OpenTemporaryWindow = FCF_OpenTemporaryWindow

FCF_OpenTemporaryWindow = function(...)
	local frame = hooks.FCF_OpenTemporaryWindow(...)
	hooks[frame] = frame.AddMessage
	frame.AddMessage = AddMessage
	return frame
end

Since neither method breaks any parts of the default UI, its easier (less code, and less hooking) and more efficient (no need for 10 string replaces per chat message per frame) to just overwrite GetColoredName.

[Haleth]

Thank you for the reply, I'll try out the method that you posted.

The strange thing is that I'm only able to reproduce the error *sometimes*. Most of the time, cancelling buffs works fine, while at other times, it doesn't.

I'm going to try a few different situations but I'm really quite stumped on this.