Yeah, in fact since there are no cancelable debuffs (to my knowledge) there is no actual advantage from a functionality standpoint to using SecureAuraHeaderTemplate for debuffs. However, from a development standpoint, once you write an addon that uses SecureAuraHeaderTemplate to support buffs, supporting debuffs is very easy since it uses the exact same infrastructure. All of the events, hooks, frame code, etc. is the same.

To ditch the SecureAuraHeaderTemplate debuff header and create those frames with manual scanning etc. would certainly be possible, and would allow the addition of blacklists or whitelists or whatever. The problem is that very little (complete guess: maybe 10 to 20%) of the code currently in bBuffBars would be reusable for this purpose, compared to the current situation of debuffs reusing 90%+ of the buff code. So essentially it would just be coding a classic-style uncancelable buff/debuff addon with all its own event code, frame code, etc. and tacking it on to the end of the current addon with very little interaction.

Functionality-wise, it's a clearly winning idea since the shackles on SecureAuraHeaderTemplate don't win us anything when it comes to debuffs. However from a practical standpoint, it's much more difficult and basically boils down to starting from scratch since so little of the current code can be used in the non-secure alternative. So while it's certainly possible, it's probably outside the scope of what I personally want to do with this addon given that I don't have a burning need for this kind of thing myself.

Thanks. Anyway, basically what you're saying is correct. There isn't really any way to do filtering when using SecureAuraHeaderTemplate--we're completely limited to whatever filtering is provided by Blizzard for use with SecureAuraHeaderTemplate and no more. That amounts essentially to changing the sort ordering alone (based only on a few preset criteria), and potentially filtering out buffs that Blizzard considers to be "consolidated" (as in the default UI), which in itself is not changable (nor currently tested/supported in this fork of bBuffBars).

So essentially the situation is that using SecureAuraHeaderTemplate, we have no control of which buffs get buttons on our screen--they all do, always. All that can be done is change their appearance in some way. Currently for instance, to work around the weapon enchant bug, I'm setting some buffs to be almost invisible (0.05 alpha, but 0 is possible too). However, there is no way to actually remove the underlying button, which will remain clickable, or to move it to the end of the list or whatever. All frame positioning is done by Blizzard's code.

So if highlighting and dimming etc. works for your filtering needs, it's doable. If not, it isn't. Unfortunately, that's the lot we've been dealt when using SecureAuraHeaderTemplate, and as you correctly observed, it's resulted in a lot of buff/debuff trackers either having to forego buff canceling entirely, using out-of-combat canceling only, or using some sort of hybrid system with preset lists that create aura cancelling frames at a fixed point.

In any case, as an addon (or addon fork) that submits itself as much as possible, for better or worse, to the SecureAuraHeaderTemplate system, none of those hacks really make a good fit. So to cut a long story short--we're stuck with what we have, and what we have is changing how the bars look--and little if anything else.

I think your current solution, though awkward, is probably the best you're going to be able to get with both completely in-combat-cancelable buffs, and filterable debuffs. This addon specializes in the former, and there are other addons that specialize in the latter. Blizzard doesn't really provide an easy way for a single type of addon to do both since each requires a completely different system to work.

One more fix in the "experimental" branch related to weapon enchant bugs. Ranged weapon enchantments no longer cause errors in 0.25experimental.

However, again due to bugs in Blizzard's code, ranged weapon enchants being applied or expiring will not cause the buff list to update immediately. Such enchantments will only appear or disappear the next time another buff updates.

I have uploaded a new version called 0.24experimental. It attempts to implement an ugly work-around for the bug Blizzard created in 4.3 when weapon enchants are shown.

If you don't use weapon buffs or are willing to turn them off, please consider using 0.23 instead as it will use less memory.

As for how it works, if it detects a buff appearing on you twice, or an "invalid" buff, it sets the alpha for the invalid/duplicate buff line to 0.05 (almost invisible). The bar is still there, can still be clicked, etc., as there's nothing I can do about that. But this may reduce the visual clutter caused by the bug.

Note that this fix depends on the order buffs appear in and so forth and may not work depending on your sorting options (though I think it should be okay). As a result, more memory is used since a new table has to be created to check for duplicates each time buffs are updated. Problems may also occur when weapon buffs are manually canceled or expire, though they should not be too severe.

Okay, after testing on a different character I now see the bug. It's related to weapon enchantments (which is why I didn't notice this problem on my warlock, but just testing now on my rogue, I do).

Now the problem is this seems to actually be a Blizzard bug. Instead of fixing the countless issues and bugs already in their SecureAuraHeader code, they have instead added new ones with patch 4.3.

I found these threads related to the problem:

http://eu.battle.net/wow/en/forum/topic/2868633701#1
http://us.battle.net/wow/en/forum/topic/3580989647
http://us.battle.net/wow/en/forum/topic/3424690010
http://www.tukui.org/forums/topic.php?id=17050

Right now I'm not sure there is any work around, except to disable weapon enchantments from showing on the bar (i.e. set includeWeapons to nil). I will look into the issue some more but for now, I don't know if there is anything I can do since the problem is in Blizzard's protected code that addons can't touch.

I just posted an update for 4.3 (may still be pending, check the changelog to see). However, it only contains one very, very small icon border fix (not related to the patch). Other than that, it is only a TOC update. So updating may not be necessary for people who are happy to edit their own TOCs or enable outdated addons.

Of course, if you actually find any bugs since 4.3, let me know. I haven't run into any.