Taint in Cataclysm is even worse!
 

So basically what I did was to redefine a function by copying it from FrameXML and altering 1 line in it so the time format on buffs and debuffs could be what ever I want it to be (format). The problem is that it now does not even accept canceling buffs when you right-click, it asks for the addon to be disabled.

My question is if there are some API changes that I didn't notice? How could one alter the behavior of API such as "UnitAura" (or any other API) that requires pre-hooking and not post-hooking?

Another question of mine is since you now can't use (self, event, ...) and you must specify the amount of arguments such as (self, event, arg1, arg2) -is there a work around? Or did it just mean you can't have variables such as "local self, event, arg1, arg2 = 1,2,3,4" defined in an addon as they are restricted? Just need clarification on this. I prefer using "..." then using "arg1" and such in the body itself.

I believe it's CancelUnitBuff() that's Blizzard only now. Dunno if that's intended or just a bug.

You can still use varargs. What they removed where global vars called this, arg1, arg2, etc., that were set internally before an event was fired.

But why would doing:
function AuraButton_UpdateDuration(auraButton, timeLeft)
<same content of function as found in FrameXML except 1 line changed to format the duration as "MM:SS">
end

Totally break the ability to even cancel a buff? It says "Action blocked, X addon tainted. Disable or Ignore." -_-' It didn't happen before 4.0 and works on 3.3.5!

CancelUnitBuff is protected in Cata. This is probably because of trickery where people considered auto-canceling stam buffs on Lich King to dispose of Infest.

I don't know what the new alternative is.

There's a secure aura header. The file isn't loaded yet however.

Does this mean Buff addons won't work anymore? A simple repositioning of the buff and debuff anchors out of combat will work but autosorting in combat while still beeing able to click cancel your buffs possibly won't, issn't it?

NO ****ING PANICKING

Cancelling buffs is now protected. Action Bar mods work with protected frames, so buff mods can do also.

@OP: Now you shouldn't rewrite the whole function, merely hooksecurefunc() it.

It really depends how extensive the sorting and filtering options in the secure handler are. Filtering sounds like a security nightmare though. There has to be some basic filtering to make the buff box work, but I don't expect much more.

This is the same sort of panic that occurred when WoW 2.0 rolled out and people thought action bars were done and gone forever.

Buff Bar addons will continue to exist in Cataclysm. They just may need to be re-written to some extent.

The ugly problem that popped up with with CancelUnitBuff() is the exploitation of the druid Eclipse buff prior to patch 3.3. In all likelihood, Blizzard just wants to ensure that when a buff is prematurely canceled by a player it is in response to a hardware event (i.e. a mouseclick)

But I want to with a simple script alter how the time under buff buttons is shown. hooksecurefunc would add more CPU cycles than necessary, right? I mean it's better to replace than to append cycles.

Also I want to for example have the ability to change one argument that UnitAura returns (based on my preferences), it's much simple to do that rather than writing a whole new addon just to alter 1 small thing. :(

We need a "prehooksecurefunc" that alters functionality before the function is called or something, with the ability to skip running the original one. :(

This would defeat the point of having a secure environment.

I know, just sad that stuff like UnitAura must be so darn protected. It only tells you about buff/debuff information, would be nice to change consolidation and how it works. Or the debuff time shown on the default frames, you dont need a lot of code to change it but you do if they make everything so strict, not to mention you just reduce the performance ever so slightly by adding more routines just to edit the original interface. :/

I am depressed.

Bear in mind that the 'secure' part is only required for the actual click-to-do-something functionality. There's absolutely nothing stopping AddOn code from layering on top of the frames any amount of 'decoration', including but not limited to:

* Labels
* Images
* Timers
* Big flashing "Click here now" arrows

The secure snippets already support a RunMethod mechanism on frame handles that executes an arbitrary method non-securely (in a sort of securehook'ish way).

In theory that's all you should need to do practically any kind of presentation (other than sorting/filtering/dynamic placement). If there are any limitations that prevent this from working appropriately please raise concerns and so we can request that the template be improved accordingly.

Would it be too much to ask for a function to hook API (within reason) and alter behavior before it actually runs the arguments trough the function?

For example some addon uses UnitName and you would like to alter the input arguments at specific conditions, so that when UnitName(...) actually runs it uses the modified arguments and not the original once.
I guess what I am getting at is something like a:
Calling /dump UnitName("player") would actually run UnitName("target").
In this situation, calling /dump UnitName("player") would return {"Playername", "MyRealm"} and avoid running the original "UnitName". Problem here is that using multiple addons that do this on UnitName would clash but it's just a suggestion and there are probably other ways that this problem can be avoided.

In short, this could be used to alter simple default UI function behavior in a efficient way (no proof to backup my statement, I just suspect it could be if we can avoid making those "local orig = FuncName and re-declaring the function over again).

It's just a suggestion, I think you understand what I am trying to get across.
Thanks for reading my rant. :)

You would be looking to create a pre-hook, as opposed to a post-hook.

See here: http://www.wowwiki.com/Hooking_functions

You can do that now, but you can't do it with any functions that the secure part of WoW uses because such a thing would cause massive taint. That's the reason why the existing hooksecurefunc does not allow you to change the result of the function - because if it did you'd either taint the UI, or be able to subvert the protections against automation.

A specific example, why is UnitAura causing massive taint and makes it impossible to cancel player buffs if tainted in Cataclysm? I guess I just don't see how one could abuse this API by modifying how it's runned...

Also just modifying how buff timers are shown also taints it so bad that you can't cancel buffs, perhaps this is a bug that will be resolved later on? Just curious if not like what other ways could we use to modify the numbers below buffs or what buffs consolidate and not. :)

*Edit*

Iriel: when I use the implemented LevelUpDisplay frame to show a fake message, if I set LevelUpDisplay.level to anything less than 10 (example 0) it will crash the game when the animation tries to play back. Example for a macro that you can use to crash on purpose:
I did submit the crash reports so I hope the core devs have some fun with it. :3

You're missing a few different points here that I'd like to try and clarify. The first and most important is that you don't need to alter the original function in order to do what you want to do. Consider the aura system a completely closed box that you cannot alter the code of in any way. How could you accomplish what you want to do?

You could write a function that hides the original timer FontStrings and replace them with your own, in your own format, with your own conditions. This code can run on top of the Blizzard aura system without any taint and you get precisely what you want.

Alternatively, you can wait and see if there's going to be secure template support for the aura system, in which case you'll almost certainly be able to do what you want in another way entirely.

The reason that altering that function causes taint is because that is how the taint system works. In some cases Blizzard writes their code in a way that makes it easier for us to directly customize things, but that's not always possible or feasible.

To reiterate: You can do what you want to do, get precisely the same effect, you just cannot do it the way you're trying to do it.

I understand. I was just curious if there are ways to do this without affecting performance in a bad way.

Running code on top would in fact cause first the default UI to render it as it is supposed to, then my code would go over and for example consolidate buffs that I want to hide by force. This would reduce performance to a certain extend, it depends on many things tough.

Thanks for explaining in debt Cladhaire. Perhaps we can hope that the devs that work on the default UI may leave some ways for addons to customize certain things, for once having the consolidateBuffs local makes it harder to add or remove entries from it, I guess this being global would have saved us authors a lot of time and performance impact when you think about it. ^_^