Blizzard Nameplates - Threat

Blizzard Nameplates - Threat

125k Downloads

calling 'Hide' on bad self (Usage: self:Hide()) [string "=[C]"]: in function `Hide'

dieterdanger opened this issue ยท 18 comments

commented

1x ...e/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua:867: calling 'Hide' on bad self (Usage: self:Hide())
[string "=[C]"]: in function `Hide'
[string "@Interface/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua"]:867: in function <...e/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua:866>

Locals:
(*temporary) = NamePlateTooltip {
waitingForData = false
layoutType = "TooltipDefaultLayout"
textLeft1Font = "GameTooltipHeaderText"
BottomOverlay = Texture {
}
textRight1Font = "GameTooltipHeaderText"
NineSlice = Frame {
}
TextRight1 = NamePlateTooltipTextRight1 {
}
TextRight2 = NamePlateTooltipTextRight2 {
}
TextLeft2 = NamePlateTooltipTextLeft2 {
}
TopOverlay = Texture {
}
comparing = false
0 =
needsReset = true
textLeft2Font = "GameTooltipText"
textRight2Font = "GameTooltipText"
TextLeft1 = NamePlateTooltipTextLeft1 {
}
updateTooltipTimer = 0.168000
}

commented

A few rare times I can see mobs wandering about with one/more random buff icons under their nameplate, if I hover mouse over those icons I get an error below similar to what you found initially. My taint.log is empty though, so I'm a bit puzzled what it's coming from. I doubt it's default Blizzard UI script errors but you never know when they gotta rush Dragonflight so much, I should try some dungeon/wilderness runs with no addons + /console taintlog 2 to be sure I guess.

https://github.com/tomrus88/BlizzardInterfaceCode/blob/master/Interface/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua#L860

Message: ...e/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua:860: Usage: NamePlateTooltip:SetUnitBuffByAuraID("unit", auraInstanceID, "filter")
Time: Mon Nov 7 20:40:34 2022
Count: 7
Stack: ...e/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua:860: Usage: NamePlateTooltip:SetUnitBuffByAuraID("unit", auraInstanceID, "filter")
[string "=[C]"]: in function `setFunction'
[string "@Interface/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua"]:860: in function <...e/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua:853>

Locals: (*temporary) = NamePlateTooltip {
waitingForData = false
layoutType = "TooltipDefaultLayout"
textLeft1Font = "GameTooltipHeaderText"
BottomOverlay = Texture {
}
textRight1Font = "GameTooltipHeaderText"
NineSlice = Frame {
}
TextRight1 = NamePlateTooltipTextRight1 {
}
TextRight2 = NamePlateTooltipTextRight2 {
}
TextLeft2 = NamePlateTooltipTextLeft2 {
}
TopOverlay = Texture {
}
comparing = false
0 =
needsReset = true
textLeft2Font = "GameTooltipText"
textRight2Font = "GameTooltipText"
TextLeft1 = NamePlateTooltipTextLeft1 {
}
updateTooltipTimer = 0.089000
}
(*temporary) = "nameplate1"
(*temporary) = 3444
(*temporary) = "HELPFUL|INCLUDE_NAME_PLATE_ONLY"

commented

This might be a later symptom of the SetTargetClampingInsets "vague UI taint" issue later infecting default Blizzard UI panels (this is exactly what "tainting" does if untreated). Once that taint issue is solved this one should go away for good I hope, and hope it's not preventing important combat actions in the meantime :)

commented

Hmm the report does not mention taint in this case, so it COULD instead be a sign maybe my latest attempt to hooksecurefunc did not solve the UI taint issue but could have worsened some other problems. Still hoping once I understand and fix the vague taint that maybe I can just rollback those hooksecurefunc no longer needed so this Hide thing does not act up anymore.

commented

/console taintlog 2 gives me something like this after I fiddled around a bit in menus having the addon (and only the one addon) run for a while, it never mentions the NPT addon but that's why taint is annoying, you can't be sure where it's coming from but it MUST be NPT addon somewhere earlier: C:\Program Files (x86)\World of Warcraft_retail_\Logs\taint.log

11/3 23:53:38.749 Global variable ACTIVE_CHAT_EDIT_BOX tainted by *** TaintForced *** - Interface/FrameXML/ChatFrame.lua:4506 ChatEdit_DeactivateChat()
11/3 23:53:38.749 Interface/FrameXML/ChatFrame.lua:4443 ChatEdit_OnEditFocusLost()
11/3 23:53:38.749 ChatFrame1EditBox:hatFrame.xml:121_OnEditFocusLost()
11/3 23:53:38.749 ChatFrame1EditBox:Hide()
11/3 23:53:38.749 Interface/FrameXML/ChatFrame.lua:4940 ChatEdit_ClearChat()
11/3 23:53:38.749 Interface/FrameXML/ChatFrame.lua:5221 ChatEdit_ParseText()
11/3 23:53:38.749 Interface/FrameXML/ChatFrame.lua:4883 ChatEdit_SendText()
11/3 23:53:38.749 Interface/FrameXML/ChatFrame.lua:4919 ChatEdit_OnEnterPressed()
11/3 23:53:38.749 ChatFrame1EditBox:hatFrame.xml:127_OnEnterPressed()
11/3 23:53:38.749 Execution tainted by *** TaintForced *** while reading ACTIVE_CHAT_EDIT_BOX - Interface/FrameXML/ChatFrame.lua:4425 ChatEdit_OnHide()
11/3 23:53:38.749 ChatFrame1EditBox:hatFrame.xml:115_OnHide()
11/3 23:53:38.749 ChatFrame1EditBox:Hide()
11/3 23:53:38.749 Interface/FrameXML/ChatFrame.lua:4940 ChatEdit_ClearChat()
11/3 23:53:38.749 Interface/FrameXML/ChatFrame.lua:5221 ChatEdit_ParseText()
11/3 23:53:38.749 Interface/FrameXML/ChatFrame.lua:4883 ChatEdit_SendText()
11/3 23:53:38.749 Interface/FrameXML/ChatFrame.lua:4919 ChatEdit_OnEnterPressed()
11/3 23:53:38.749 ChatFrame1EditBox:hatFrame.xml:127_OnEnterPressed()

commented

These tainting issues are nasty ones indeed. I'll try to reproduce them (right now it happens in dungeons) with taintlog enabled and post my results.

Being a developer myself I'm asking how an addon developer could prevent producing taints. How do I know if I wrongly touch secure code by Blizzard? Or is all Interface code by Blizzard secure?

commented

I think the core of the problem is NPT addon changes the color of default Blizzard nameplates.

https://wowpedia.fandom.com/wiki/Secure_Execution_and_Tainting

"When code sets global values, the resulting value has the taint of the execution path."

And then afterward Blizzard nameplates logic eventually read those changed color values, and the taint spreads, eventually so far that it blocks certain user actions during combat. But yeah I kinda HAVE to set those color values during combat or the addon is useless. Only alternative I see right now is drawing custom NPT nameplates on top of the Blizzard ones and only touching those. It sort of defeats the purpose of keeping the addon light weight and blizzlike though. There are many other addons out there already accomplishing what NPT does for custom nameplates so... Yeah I dunno.

commented

I'm getting these in taint.log:

11/4 21:29:52.721 CompactUnitFrame_UpdateName()
11/4 21:29:52.721 An action was blocked in combat because of taint from NamePlatesThreat - SetTargetClampingInsets()
11/4 21:29:52.721 Interface/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua:395 NamePlateDriverFrame:SetupClassNameplateBars()
11/4 21:29:52.721 Interface/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua:143 NamePlateDriverFrame:OnNamePlateAdded()
11/4 21:29:52.721 Interface/AddOns/Blizzard_NamePlates/Blizzard_NamePlates.lua:78

So that would mean NPT changes values that are read in CompactUnitFrame_UpdateName(), doesn't it?

commented

Yeah, probably the monster's name color (changed to threat color when target is selected and border coloring is enabled for instance). SetTargetClampingInsets() probably is just the symptom many other addon developers have seen when the taint becomes severe enough, blocking the combat action.

Most of the addon code is just threat calculations, but updatePlateColor and resetFrame functions set the Blizzard name/plate border/healthbar color and alpha values. although they don't directly set the colors they go though Blizzard functions to set them which should cause less taint. Some sort of hooksecurefunc I think can be used to lessen taint if still necessary but I haven't had much luck in previous versions.

It could also be the new .threat object I add to each nameplate, basically it's just a small table holding that nameplate's intended threat color, threat situation, and last color/situation/similar variables. Maybe my adding such a new object to Blizzard nameplates infect them with taint, so I should instead keep a dictionary separate of the nameplate but find a way to correspond that dictionary with the current nameplate being processed for coloring.

commented

Try replacing your nameplatesthreat.lua with that from https://raw.githubusercontent.com/int3ro/Nameplates_Threat/mikfhan/NamePlatesThreat.lua in mikfhan branch for latest 3.4-release work in progress, the taint is still there but now I use a dictionary/list called NPT.threat (indexed by the plate.namePlateUnitToken string) instead of a frame.threat object. My hope is the causes for taint have been reduced, but there are still some left to avoid altering Blizzard UI element values (maybe those require hooksecurefunc it's hard to tell currently). One benefit is it seems memory/cpu usage has been reduced, that's something at least.

commented

Nice, yeah I'm seeing the same, the targeted (either dragonflight soft or traditional hard) monster DOES change its name color to threat status, but then something flips it back to Blizzard default red color again. I color the name on targeted mob instead of nameplate border since you need the white border to see which nameplate is targeted. Just gotta find some way to keep the name colored by threat without it being overridden soon after.

Color gradient enables a continuous update loop that will recolor the name 1-9 times per second that to some extent fixes the issue but the color is briefly red/wrong annoying anyway, so something else needs doing also if gradient is disabled - maybe I could just color the border when selected anyway, the name being visible should indicate just fine what monster is targeted, unless multiple show their name during quests and such :P Thanks for the code suggestions and help testing!

commented

The aforementioned file does not seem to reduce taints, unfortunately. To narrow down the root cause I began commenting out whole parts of the lua code.

local function resetFrame(plate)
if plate.UnitFrame then
if plate.UnitFrame.unit then
-- CompactUnitFrame_UpdateName(plate.UnitFrame)
-- CompactUnitFrame_UpdateHealthBorder(plate.UnitFrame)
-- CompactUnitFrame_UpdateHealthColor(plate.UnitFrame)
plate.UnitFrame.healthBar.border:SetAlpha(1)
else
plate.UnitFrame.healthBar.border:SetVertexColor(plate.UnitFrame.healthBar.border.r, plate.UnitFrame.healthBar.border.g, plate.UnitFrame.healthBar.border.b, 1)
end
plate.UnitFrame.healthBar:SetStatusBarColor(plate.UnitFrame.healthBar.r, plate.UnitFrame.healthBar.g, plate.UnitFrame.healthBar.b, plate.UnitFrame.healthBar.a)
end
if NPT.threat[plate.namePlateUnitToken] ~= nil then
NPT.threat[plate.namePlateUnitToken] = nil
end
end

Commenting out the three CompactUnitFrame_* function calls leads to a taint free experience. What are these for in resetFrame? I don't see any difference in the addon functionality whether these run or not.

Best regards

commented

Good find! I've tried commenting those out but it looks like they are needed while you have "color borders only" enabled. Otherwise when you disable and click Okay in options panel, the nameplates still have their border colored when only the healthbar should be. It's basically what I tried to do with the border:SetVertexColor but that does not seem to do anything so I removed that as well.

I tried many things in latest mikfhan branch line 78-96 but maybe I should just accept that lesser bug after addon options screen. Certainly is a great tradeoff if UI taint is eliminated by it :D gotta do more dungeon runs with /console taintlog 2 and "color borders only" the next days to see if taint really IS gone, thanks for the help!

commented

I did a dungeon with "color borders only" (latest mikfhan branch) and no tainting could be observed.

One little bug though: the target nameplate border is not colored correctly. Instead, the target nameplate name is cycling through different colors. Nameplates that are not directly targeted work flawlessly.

commented

Neat :P yeah think I stumbled on it from a few google searches before - latest version on mikfhan branch now listens on UNIT_THREAT_LIST_UPDATE and UNIT_TARGET it seems so far it does most of what's needed :)

commented

Latest version always color border now instead of name of selected target, but yeah the nameplate still reverts to white/normal border in some cases. I can often reproduce it by enabling Dragonflight action/soft targeting under options > combat at the bottom, then target myself and approach a monster (dungeon or no dungeon does not matter).

Initially their nameplate IS colored but it's almost like there's some sort of combat/retarget event firing every time they hit me while I'm targeting myself. My target does not change but their nameplate goes back to normal color again. Maybe I gotta sift through the Blizzard UI code snippets available on the net or https://wowpedia.fandom.com/wiki/Events to guess what events might be doing that I haven't registered yet. Once I register/react on those also it should be good.

commented

Sounds good, thanks for the update! Just in case, do you know this repository?

https://github.com/tomrus88/BlizzardInterfaceCode

commented

Vindication! The same script error happens in retail without any addons enabled :) Also seeing those weird nil nil red text top of screen sometimes. Hats off for the Blizzard bughunters, can't be easy working at that pace.

Thanks a lot for the help Dieter! Unless you find something suspicious I will aim for 3.4-release this Saturday 12nov. I am out of the country when Dragonflight prepatch phase 2 releases 15nov so might as well make latest taint fixes/etc public ahead of that.

commented

Thank you mikfhan so much! Your plugin is one of my favorites! I'll report further errors if they should occur.

Best regards