Sometimes all Buttons in the Menu slide to the first entry after triggering one
negue opened this issue · 5 comments
Only happens randomly so nothing always and its fixed by closing/opening the menu again, but maybe this Callstack helps
12x [ADDON_ACTION_BLOCKED] AddOn 'UFO' hat versucht die geschützte Funktion 'SecureHandlersUpdateFrame:SetAttribute()' aufzurufen.
[string "@!BugGrabber/BugGrabber.lua"]:485: in function <!BugGrabber/BugGrabber.lua:485>
[string "=[C]"]: in function `SetAttribute'
[string "@FrameXML/SecureHandlers.lua"]:742: in function `SecureHandlerExecute'
[string "@UFO/ui/FlyoutMenu.lua"]:255: in function <UFO/ui/FlyoutMenu.lua:253>
[string "=[C]"]: in function `Hide'
[string "@FrameXML/RestrictedFrames.lua"]:382: in function `Hide'
[string " -- only trigger on mouse UP. the down variable is passed in by the Bliz API
if down then return end
if not flyoutMenu then
flyoutMenu = self:GetParent()
end
if not germ then
germ = flyoutMenu:GetParent()
end
local doClose = germ:GetAttribute("doCloseOnClick")
if doClose then
--print("CLOSING: ", germ:GetName() )
flyoutMenu:Hide()
flyoutMenu:SetAttribute("doCloseFlyout", false)
flyoutMenu:ClearBindings()
end
"]:15: in function <[string " -- only trigger on mouse UP. the down ..."]:1>
[string "=(tail call)"]: ?
[string "=[C]"]: ?
[string "@FrameXML/RestrictedExecution.lua"]:484: in function <FrameXML/RestrictedExecution.lua:447>
[string "=(tail call)"]: ?
[string "@FrameXML/SecureHandlers.lua"]:285: in function <FrameXML/SecureHandlers.lua:279>
[string "=(tail call)"]: ?
Locals:
_ = Frame {
RegisterEvent = <function> defined @!BugGrabber/BugGrabber.lua:491
0 = <userdata>
UnregisterEvent = <function> defined @!BugGrabber/BugGrabber.lua:491
SetScript = <function> defined @!BugGrabber/BugGrabber.lua:491
}
event = "ADDON_ACTION_BLOCKED"
events = <table> {
ADDON_ACTION_BLOCKED = <function> defined @!BugGrabber/BugGrabber.lua:557
ADDON_ACTION_FORBIDDEN = <function> defined @!BugGrabber/BugGrabber.lua:557
PLAYER_LOGIN = <function> defined @!BugGrabber/BugGrabber.lua:551
LUA_WARNING = <function> defined @!BugGrabber/BugGrabber.lua:566
ADDON_LOADED = <function> defined @!BugGrabber/BugGrabber.lua:511
}
UFO tried to call the protected function 'SecureHandlersUpdateFrame:SetAttribute()'
... and then a list of secure calls made by internal "secure" Bliz code. Soooooooo, yeahhhhhh. I have no reservations about laying the blame squarely on Blizzard. Now I must find a work around for their bugs. Not the first time!
I found the cause:
In response to some events, such as actionbar or inventory updates, the code will close, aka Hide(), all UFOs in order to recalculate which buttons should be visible.
My OnHide handler makes exactly one API call: SecureHandlerExecute(germ, "flyoutMenu:ClearBindings()")
That API call successfully clears all of the bindings. YAY! But, somehow shits the bed and short-circuits the actual Hide() call that originally triggered the OnHide event causing the flyout menu to only partially hide (one button remains and the flyout frame is still visible. BOOO! But hey, points for hiding almost all of the buttons, right?!? Keep trying, my lil API buddy. You're doing the best you can. Gold star for participation. Pat pat pat on the head. Now go play in traffic.
Why does it shit the bed? Because at some point inside the internal secure call chain, it decides that it has become tainted (as shown by my good friend @negue 's BugGrabber dump). Yes, SecureHandlerExecute() caused taint. SECUREHandlerExecute() SECUUUUUUUUUUUUUURE
To help the little engine that couldn't, I now have a separate frame dedicated to owning the key bindings. Now the flyout can worry about hiding. And the dedicated frame can worry about clearing the bindings. This has solved the problem with Blizzard's code... at least until they break it in some other inexplicable way.
Wow, I have absolutely no tolerance or patience for the mistakes of API devs. Maybe I should work on that. They're only human.
@negue , has this solved to the problem you saw? If so, I'll close this bug.