ESOUI - @ZOS: Improve "Access a private function" error message

ESOUI (https://www.esoui.com/forums/index.php)

- General Authoring Discussion (https://www.esoui.com/forums/forumdisplay.php?f=174)

- - @ZOS: Improve "Access a private function" error message (https://www.esoui.com/forums/showthread.php?t=6926)

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 30613)

Votan, I've been toying with that idea for the past week or so. As soon as I can reproduce the bug I'll evaluate how well it applies for this specific situation.

:o Of course. I'll keep my fingers crossed. :)

Alright, so here's what we're thinking. We'd change virtuals to always create their handler closures as trusted as long as the virtual was created during the secure part of the load process (is part of the stock UI). This should mean the mouse enter on the inventory slot is created as secure even if an addon causes the control to be created and that should prevent the tainting issue.

Sounds like that should solve all of the current iterations of the issue that I've experienced. Will this be released on the PTS?

Thank You Chip.

:o I know you will gonna hate me, but what about this classic one:

Lua Code:

if MyBadWindow then return end
 
local topLevel = WINDOW_MANAGER:CreateTopLevelWindow("MyBadWindow")
MYBADFRAGMENT = ZO_FadeSceneFragment:New(topLevel, true, 250)
WORLD_MAP_SCENE:AddFragment(MYBADFRAGMENT)

Open the world map and from there click on the crown store market.

Code:

EsoUI/Ingame/Scenes/IngameFragments.lua:461: attempt to access a private function 'StopAllMovement' from insecure code

stack traceback:

        EsoUI/Ingame/Scenes/IngameFragments.lua:461: in function 'ZO_StopMovementFragment:Show'

        EsoUI/Libraries/ZO_Scene/ZO_SceneFragment.lua:128: in function 'ZO_SceneFragment:ShouldBeShown'

        EsoUI/Libraries/ZO_Scene/ZO_SceneFragment.lua:172: in function 'ZO_SceneFragment:Refresh'

        EsoUI/Libraries/ZO_Scene/ZO_Scene.lua:291: in function 'ZO_Scene:RefreshFragmentsHelper'

        EsoUI/Libraries/ZO_Scene/ZO_Scene.lua:299: in function 'ZO_Scene:RefreshFragments'

        EsoUI/Libraries/ZO_Scene/ZO_Scene.lua:256: in function 'ZO_Scene:SetState'

        EsoUI/Libraries/ZO_Scene/ZO_Scene.lua:416: in function 'ZO_RemoteScene:SetState'

        EsoUI/Libraries/ZO_Scene/ZO_SceneManager.lua:182: in function 'ZO_SceneManager:ShowScene'

        EsoUI/Libraries/ZO_Scene/ZO_SceneManager.lua:474: in function 'ZO_SceneManager:OnSceneStateChange'

        EsoUI/Ingame/Scenes/IngameSceneManager.lua:326: in function 'ZO_IngameSceneManager:OnSceneStateChange'

I think it is the ZO_Scene:SetState(newState) which does all the state change callbacks to build-in code.

Quote:

Originally Posted by Rhyono (Post 30620)

Sounds like that should solve all of the current iterations of the issue that I've experienced. Will this be released on the PTS?

I'll try my best.

Quote:

Originally Posted by votan (Post 30623)

Thank You Chip.

:o I know you will gonna hate me, but what about this classic one:

Lua Code:

if MyBadWindow then return end
 
local topLevel = WINDOW_MANAGER:CreateTopLevelWindow("MyBadWindow")
MYBADFRAGMENT = ZO_FadeSceneFragment:New(topLevel, true, 250)
WORLD_MAP_SCENE:AddFragment(MYBADFRAGMENT)

Open the world map and from there click on the crown store market.

Code:

EsoUI/Ingame/Scenes/IngameFragments.lua:461: attempt to access a private function 'StopAllMovement' from insecure code

stack traceback:

        EsoUI/Ingame/Scenes/IngameFragments.lua:461: in function 'ZO_StopMovementFragment:Show'

        EsoUI/Libraries/ZO_Scene/ZO_SceneFragment.lua:128: in function 'ZO_SceneFragment:ShouldBeShown'

        EsoUI/Libraries/ZO_Scene/ZO_SceneFragment.lua:172: in function 'ZO_SceneFragment:Refresh'

        EsoUI/Libraries/ZO_Scene/ZO_Scene.lua:291: in function 'ZO_Scene:RefreshFragmentsHelper'

        EsoUI/Libraries/ZO_Scene/ZO_Scene.lua:299: in function 'ZO_Scene:RefreshFragments'

        EsoUI/Libraries/ZO_Scene/ZO_Scene.lua:256: in function 'ZO_Scene:SetState'

        EsoUI/Libraries/ZO_Scene/ZO_Scene.lua:416: in function 'ZO_RemoteScene:SetState'

        EsoUI/Libraries/ZO_Scene/ZO_SceneManager.lua:182: in function 'ZO_SceneManager:ShowScene'

        EsoUI/Libraries/ZO_Scene/ZO_SceneManager.lua:474: in function 'ZO_SceneManager:OnSceneStateChange'

        EsoUI/Ingame/Scenes/IngameSceneManager.lua:326: in function 'ZO_IngameSceneManager:OnSceneStateChange'

I think it is the ZO_Scene:SetState(newState) which does all the state change callbacks to build-in code.

Honestly this probably doesn't need to be a private function. But you could also reduce the duration of the fade to be shorter than 200ms and it wouldn't be the fragment that triggered the show on the crown store scene.

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 30626)

:D Yes. I know that. We tracked that down. Was just a try.
Would it be possible to defer the call to private function with a EVENT_MANAGER:RegisterForUpdate("<id>", 0, localFunction) to remove the tainted call-stack ?

Alright, so here's what has gone in internally:

The security error now indicates which part of the stack was the first thing to be tainted.
Script handlers from trusted virtuals are now trusted.
StopAllMovement is public
I also increased the max length of the lua stack trace from 10 to 30

Hopefully all of this should make it for Morrowind. I've tested both of the errors listed in this thread and both are fixed with these changes.

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 30664)

Alright, so here's what has gone in internally:

The security error now indicates which part of the stack was the first thing to be tainted.
Script handlers from trusted virtuals are now trusted.
StopAllMovement is public
I also increased the max length of the lua stack trace from 10 to 30

Hopefully all of this should make it for Morrowind. I've tested both of the errors listed in this thread and both are fixed with these changes.

Thank You very much.
This will help us a lot. :banana:

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 30664)

Alright, so here's what has gone in internally:

The security error now indicates which part of the stack was the first thing to be tainted.
Script handlers from trusted virtuals are now trusted.
StopAllMovement is public
I also increased the max length of the lua stack trace from 10 to 30

Hopefully all of this should make it for Morrowind. I've tested both of the errors listed in this thread and both are fixed with these changes.

Can't wait for it. :D

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 30664)

Alright, so here's what has gone in internally:

The security error now indicates which part of the stack was the first thing to be tainted.
Script handlers from trusted virtuals are now trusted.
StopAllMovement is public
I also increased the max length of the lua stack trace from 10 to 30

Hopefully all of this should make it for Morrowind. I've tested both of the errors listed in this thread and both are fixed with these changes.

Wonderful! I honestly can't count on one hand the number of people who have complained recently in guild or TeamSpeak about constantly having to reload their UI after encountering these types of errors. This change will be a dramatic improvement for the population of the game who run trading addons, etc.