My addon started tainting FocusUnit()
 

Hello,

Recently people started complaining about my addon giving them taint lua errors, connected to FocusUnit().
I didn't change anything in my addon for months, so I don't know why this errors started just now.

Anyway, my addon doesn't use any focus related api. I've made some searches and found out that it can be related to my addon using a dropdown menu (I use it for the user to select a font from a list of fonts).

Is it indeed the dropdown menu that causes the lua error?
Is there an easy way to resolve this issue? because people stopped using my addon because of this error.

I attach an example of the error my addon does. Any help is appreciated!

Oh boy! *getting popcorn*

Man...why is the dropdownmenu ****ed up like that?

I understand that this may be a joke for some of you... But I've just came back from few months absence, and I'm trying to fix this addon.

So I would really appreciate some help here... :)

I will let someone else explain dropdown taint, I am afraid I may say something wrong. :P

*Edit*

I suspect the issue is taint with dropdown, and for the love of god I can't find some post summarizing why and how to deal with this issue, that's why I couldn't post a good reply.

Any addon touching any dropdown menu anywhere at any time will taint the entire dropdown menu system, breaking the focus menu commands and all other secure menu commands. The only solution is to write your own dropdown system from scratch (or find a library that does it) and not touch anything remotely related to the Blizzard dropdown menu system in any way at any time.

My experience suggests that this isn't necessarily true; I'm running several addons that use the UIDropDownMenuTemplate and "Set Focus" works without any issues on Blizzard unit frames for me.

Personally, I'd be interested in seeing any concise addon interaction with UIDropDownMenu API that reliably ends up tainting the entire thing.

Taint-related errors are sometimes caused by interaction between several pieces of code. Even if your addon hasn't been updated for months, patch 5.0.x updates to FrameXML and other addons may have contributed here.

Unfortunately, the problem isn't trivial to debug. Try asking your users whether they still get that error with only your addon enabled; and, if so, if they can come up with some short sequence of actions that reliably causes the error to appear for them. Getting a taintlog of the problem occurring might provide some additional information as to what's actually going on.

The problem is that if we could follow the spreading of taint so we can reliably reproduce it we'd solve it (actually Blizzard would have solved it)

Nevertheless, addons that use he default UIDropDownMenuTemplate and at some point initialize it to more menuitems or levels than are securely initialized by Blizzard code as the game loads (8 and 2 respectively) eventually get blamed for action blocked errors.

Sometimes this only happens after a couple hours of raiding which means the spread of taint through the UI is stochastic in nature because there's no surefire way to trace the calls throughout.

This analysis from 2008 by Telic remains relevant even when the exact sequence to reproduce the problem might not be.

Because the codepaths through taint spreads have changed with subsequent versions of the game but the basic mechanism hasn't.

Taint propagation through UIDROPDOWNMENU_MAXBUTTONS / UIDROPDOWNMENU_MAXLEVELS, as described in the post you linked, was addressed in patch 3.0.8. As far as I can test, creating a dropdown menu with a larger number of items/levels does not taint those variables on the current live client. It seems to me that the specific mechanism you're describing hasn't been a problem for a few years now.

Well the thing is regressions in Blizzard code are not a thing unheard off.

A lot of previously solved bugs have made a re-appearance and afaik dropdown taint was never conclusively "solved"; various parts of the code were "hardened" (in their own language) which suggests they fix it on a case by case basis which is both slow (being iterative) and unreliable.

An example of dropdown menu related taint in the current game:
http://us.battle.net/wow/en/forum/to...24969?page=1#2

Thank you for your answers, people, I appreciate your trying to assist me.
Some users reported to me that this lua error stopped appearing after they removed my addon, so I guess that this is my addon's fault.
I don't want to rewrite my addon using ace3 library just for that, it will take me a lot of time since I'm not very experienced in coding. In fact, this was my first addon (out of two), and when I wrote it, I wasn't even aware of ace3 library.
I use the dropdown in order for the user to choose a font in the config panel, out of a list of 13 fonts. I can narrow it to 8 fonts, but I understood from the answers here that this will not solve the issue.

I will put the relevant code here, perhaps one of the experts will point me to the problem just from reading it.

hebChat.xml:
hebchat.lua:

There's nothing substantially wrong with your code as far as I can see. I'd recommend still asking people if they get the error with only your addon enabled -- that's the only way to guarantee that the cause of the issue is confined to your code (and FrameXML).

If you felt like stabbing at something at random, try delaying the initialization of your dropdown until your configuration panel actually needs to be shown (i.e. do the UIDropDownMenu_Initialize() call in the panel's OnShow, not the dropdown's OnLoad) -- if the issue actually stems from your use of the dropdown, this'll make it go away if the user doesn't open your configuration panel, which is probably a reasonable workaround.

Thank you; that is at least interesting to look at. It's unfortunate that the topic ended with someone blaming UIDROPDOWNMENU_MAXBUTTONS, which is the incorrect conclusion in that case -- we'll never get this fixed if we keep crying wolf at the wrong things.

Curiously, the issue occurs when you create a dropdown with 8 entries before CUFProfiles loads, even if UIDROPDOWNMENU_MAXBUTTONS >= 8 at the time of creation, isn't modified, and remains secure. This warrants a closer look, I think.

Thank you for your answer!

If I understand correctly your suggestion, it will eliminate the problem as long as the user doesn't open the config panel. But if the config panel is opened even once, then the problem will occur again. Did I get it right?

And to the technical side of implementing it: where should I define the onshow? on the xml, near <OnLoad>?

Is that your own investigation? Because nowhere in the post Dargen linked does it claim that to be the case.
What he says is that even in the situation where the CompactRaidFrame1 would end up tainted because your dropdown was created before CompactRaidFrame1, it is not if you limit your buttons to less than 8.

You got it right, but there's a certain amount of uncertainty because we don't know exactly what the problem is here. It might also be the case that making the change will make the problem go away even if your config panel is eventually shown. It may also be the case that the taint is actually caused by something else, in which case delaying initialization won't help you at all.

Yes. You could basically replace the <OnLoad></OnLoad> tags with <OnShow></OnShow> in the XML snippet you posted; but you'll also need to mark your config panel as hidden initially to prevent the OnShow from running immediately upon frame creation (add the lime-highlighted part to your existing xml code):



Yes, it is an observation from my own testing against the current live client.

Hi,

Just to made something clear: if I change the <OnLoad> to <OnShow> in the code I gave, as you suggested, it will change the dropdown frame, not the config panel. Since the <OnLoad> in my code belongs to the dropdown frame.
And according to what you wrote earlier, I should put the init function in the <OnShow> of the config panel father, not in the <OnShow> of the frame. Right?