Working around creating insecure dialogs

[Moohemoth]

Hey all! Got an issue:

https://forums.elderscrollsonline.co...n-gamepad-mode

Just like in this thread on the forums, where if your addon is the first one to make a gamepad dialog then all further dialogs, like the one activity finder makes when your queue pops, are deemed insecure and gives you errors because of it.

/EsoUI/Ingame/PlayerToPlayer/PlayerToPlayer.lua:1464: Attempt to access a private function 'CancelTaskbarWindowFlash' from insecure code. The callstack became untrusted 3 stack frame(s) from the top.
stack traceback:
/EsoUI/Ingame/PlayerToPlayer/PlayerToPlayer.lua:1464: in function 'ZO_PlayerToPlayer:RemoveEntryFromIncomingQueueTable'
<Locals> self = [table:1]{lastFailedPromptTime = 4047797, hasResurrectPending = F, hasRequiredSoulGem = F, showingResponsePrompt = F, msToDelayToShowPrompt = 500, shouldShowNotificationKeybindLayer = F, isBeingResurrected = F, failedRaidRevives = F, resurrectable = F}, index = 1, incomingEntry = [table:2]{messageFormat = 7700, acceptText = "Ready", seen = T, expiresAtS = 4273.5825195312, pendingResponse = T, dialogTitle = "Activity Finder", incomingType = 13} </Locals>
/EsoUI/Ingame/PlayerToPlayer/PlayerToPlayer.lua:1406: in function 'ZO_PlayerToPlayer:Decline'
<Locals> self = [table:1], incomingEntry = [table:2], index = 1 </Locals>
/EsoUI/Ingame/Globals/InGameDialogs.lua:3590: in function 'buttonCallback'
<Locals> dialog = ud </Locals>
/EsoUI/Libraries/ZO_Dialog/Gamepad/ZO_GenericDialog_Gamepad.lua:25: in function 'callback'
<Locals> pressState = F </Locals>
/EsoUI/Libraries/ZO_KeybindStrip/ZO_KeybindStrip.lua:680: in function 'ZO_KeybindStrip:TryHandlingKeybindDown'
<Locals> self = [table:3]{batchUpdating = F, insertionId = 500, allowDefaultExit = T}, keybind = "DIALOG_NEGATIVE", buttonOrEtherealDescriptor = ud, keybindButtonDescriptor = [table:4]{onShowCooldown = 2000, sound = "Dialog_Decline", keybind = "DIALOG_NEGATIVE", alignment = 1}, enabled = T </Locals>
(tail call): ?
/EsoUI/Libraries/ZO_Dialog/ZO_Dialog.lua:1268: in function 'ZO_Dialogs_ButtonKeybindPressed'
<Locals> keybind = "DIALOG_NEGATIVE", dialog = ud, handledButton = F </Locals>
:1: in function '(main chunk)'
<Locals> keybind = "DIALOG_NEGATIVE" </Locals>

I'm working around it now by just showing normal keyboard dialogs instead and letting the native UI make and use its own, untainted gamepad flavored ones, but would anyone know any other way around this? Anyway to call some protected function beforehand to force the game to make its own dialog so my addon doesn't make it first maybe? As far as I know, ZO_Dialogs_ShowDialog isn't a protected function so I can't just use CallSecureProtected and have it all work, so I'm kinda stuck here lol

[Baertram]

Most gamepad stuff gets initialized deferred means it is not loaded until shown first time. So if you add or hook there it will throw nil errors or get insecure code due to addons adding code before all was loaded properly (inventory at keyboard e.g. often was causing this if you tried to change it before it was initialized properly). ZOs added hook functions like SecurePostHook to circumvent this at keyboard stuff, hopefully at gamepad code too.

code gets tainted if you hook or add into it before it was loaded properly. try to use SecurePostHook at dialog functions to make your hooks secure, or add a ZO_PostHookHandler on the OnShow or OnEffectivelyShown (dialogs control) then hide the dialog directly and show your own dialog. Maybe it will make the original load, make all secure and then your dialogs can work afterwards. Could maybe make it flicker once but after that you maybe are able to replace the complete dialogs without getting insecure errors.

[Moohemoth]

Originally Posted by Baertram Most gamepad stuff gets initialized deferred means it is not loaded until shown first time. So if you add or hook there it will throw nil errors or get insecure code due to addons adding code before all was loaded properly (inventory at keyboard e.g. often was causing this if you tried to change it before it was initialized properly). ZOs added hook functions like SecurePostHook to circumvent this at keyboard stuff, hopefully at gamepad code too. code gets tainted if you hook or add into it before it was loaded properly. try to use SecurePostHook at dialog functions to make your hooks secure, or add a ZO_PostHookHandler on the OnShow or OnEffectivelyShown (dialogs control) then hide the dialog directly and show your own dialog. Maybe it will make the original load, make all secure and then your dialogs can work afterwards. Could maybe make it flicker once but after that you maybe are able to replace the complete dialogs without getting insecure errors.

Yeah, that makes sense. I'm already using SecurePostHook on every hook I make, like so:

SecurePostHook(ZO_Armory_Gamepad, "RefreshBuildList", BetterArmory.RefreshBuildList)

That one so I can add new entries to the armory's build list, and:

SecurePostHook(ZO_ARMORY_MANAGER, "ShowBuildOperationConfirmationDialog", BetterArmory.ShowBuildOperationConfirmationDialog)

So I can know when the player tries to restore/save a build. I use buildIndexes way out of normal bounds for my own purposes, which the game, at least for now, just straight up ignores and does nothing with which brings up no dialog and also lets my own code run pretty much out of the way of the native UI. The hook function only does a few checks, and then shows its own dialog, which explains the gamepad dialog only just now loading and becoming insecure because of where it's at. Was the most straight forward way of doing it that I found, maybe I'm missing something but no matter which way I hooked it without the original dialog I would've ran into this same issue anyway.

Your idea to hook and hide the original dialog myself before continuing with my own code sounds like it would work tho! Gotta change and figure out a bunch of stuff to make it work, but I'll leave that for tomorrow methinks. When it's not 4am lol