Looking for addon causing a bug

[DerBombo]

Hey there,

I have an annoying bug for quite some time, and I can't figure out, which addon is actually causing it. It doesn't happen all the time, but rather sporadic. Sometimes, when I try to use the context menu in my inventory, to either Destroy and item or get one from my bank, I get the following message:

EsoUI/Ingame/Inventory/InventorySlot.lua:903: attempt to access a private function 'PickupInventoryItem' from insecure code
stack traceback:
EsoUI/Ingame/Inventory/InventorySlot.lua:903: in function 'InitiateDestroyItem'
EsoUI/Ingame/Inventory/InventorySlot.lua:1453: in function 'OnSelect'
EsoUI/Libraries/ZO_ContextMenus/ZO_ContextMenus.lua:412: in function 'ZO_Menu_ClickItem'
8371350907706105899:4: in function '(main chunk)'

Does anyone have a tip for me in how to find out, which addon (if any) is actually causing this? I have way to many addons at the moment, to go by trial and error. Also when I reloadui, the bug isn't happening anymore for a certain amount of time.

Thanks for any help.

Edit: I'll just add all my addons here, so maybe anyone can have an educated guess.

Advanced Filters
Advanced Filters - Sous Chef Filters
AI Research Grid
AwesomeGuildStore
CDG Bank Stacker
Circonians ChatIt
Circonians EmoteIt
Circonians SortIt
Combat Cloud
Combat Log Statistics (CLS)
CurvyHud
Destinations
Dustman
FCO ItemSaver
Fully Customizable MultiQuest Tracker
Harven's Chat Completion
Harven's Improved Skills Window
Harven's Quest Journal
Harven's Subtitles
Harven's Trait and Style
HarvestMap (EsoheadMarkers)
Idle Animations
Inventory Item Borders (for Update 6)
Joviex's Addon Settings Transfer (for Update 4)
JPGScreenshot
LibMediaProvider
Librarian Book Manager
Lootdrop, Continued (All in One)
LoreBooks
MailR
MasterMerchant
MobileBank Extended
No, thank you!
pChat
PinKiller
Potion Maker
Rare Fish Tracker
Research Assistant
Runes Voices
Show Weapons While Mounted
Sous Chef - Provisioning Helper
SpentSkillPoints
Srendarr - Aura, Buff & Debuff Tracker (for Update 6)
TrueExploration
Votan's Fish Fillet
Votan's Fisherman
Votan's Rune Info
Votan's Search Box

[sirinsidiator]

You are not the only one with that issue. Maybe you can give us a list of addons that you are using.
%HOMEPATH%\Documents\Elder Scrolls Online\live\AddOnSettings.txt should contain a section for your character that shows them.

edit: thank you

[Sideshow]

If the problem is persistent, you can do a 'binary search'

First, disable the upper half of the addons
If the problem still occurs, you know it's probably not a problem with the upper half of the addons
Then, disable the upper half of the original lower half
Have fun

[votan]

Originally Posted by Sideshow If the problem is persistent, you can do a 'binary search' First, disable the upper half of the addons If the problem still occurs, you know it's probably not a problem with the upper half of the addons Then, disable the upper half of the original lower half Have fun

The problem is, it is a sporadic error. Without knowing what to do to cause it, you can not be sure.
I assume it is an general issue of ShowMenu, and the message is a misleading "always print this if any error occurs".
I think ZO_Menu_OnHide is not always called (in the right order) because the owning control gets invisible, but not hidden. (same problem as with tooltips not get closed)
And/Or some OnEffectivelyHidden handler get replaced by ShowMenu.

If I am right, you had another context-menu opened before and not closed before opening another window by key-bind.

But that's just a theory...

[sirinsidiator]

Two ideas that come to mind are 1) creating an addon that provokes this error in all sorts of ways that we can think of and 2) compare these code pieces with addons that are in the lists of people that have this problem from time to time.
Probably will be a lot of work to look through all of them though.

[DerBombo]

Thanks to all of you for your replies. Also great that each and every reply is coming from someone, whose addons I use and like pretty much. You guys are great!

Originally Posted by votan If I am right, you had another context-menu opened before and not closed before opening another window by key-bind.

That is definitely something I can look out for. Thanks Sideshow for suggesting the binary approach. I actually used that in the past to locate a different issue. The problem here is, I would have to go without half my addons for quite some time, and even then I won't be sure I caught the one messing up, because as I said the issue won't occur anymore, when I'd do a reloadui. But thanks anyway!

[DerBombo]

Also I guess I will log this as a bug with ZOS, if it's possible for them to do something about it or they are actually causing it.

[votan]

Do in chat window:
1. /reloadui
2. /script ClearMenu() AddMenuItem("") ShowMenu() ClearMenu()
3. Go and use an item of your inventory using context-menu

unsecure code?!?

Try this:
1. /reloadui
2. go and open journal and right-click a quest to open a context-menu. In fact any build-in context-menu would be ok. You could also open the context-menu of the inventory.
3. /script ClearMenu() AddMenuItem("") ShowMenu() ClearMenu()
4. Go and use an item of your inventory using context-menu

now the same code is secure

Any addon opening a context-menu before build-in code does it is unsecure.

If you add the code from above to startup code of an addon, you can not use/pickup/destory any item with context-menu anymore. But key-bind (E) would work.

ups!

[votan]

I moved the technical stuff here
If you are not an addon developer, just try the previous post.

[Kevinmon]

I have this same bug every time I play.

[votan]

Originally Posted by Kevinmon I have this same bug every time I play.

This is, what you have to care of:
Once you open a context-menu the first time after (re-)load UI, remember the position of the first menu entry introduced by an add-on. Build-in menu enties using a "private" function at the same position will raise this "security feature" error message afterwards.
Typically "private" functions are in the position 1 to 3, sometimes 4 of the inventory context-menu. Once this positions were created by build-in menu entries first, the message will not occur anymore.
If, for example, the build-in context-menu normally has 2 menu entries only and an addon introduces a 3rd menu item first time ever after load, a "private" build-in menu item at position 3 will crash.

If you have that error so frequently, what context-menu do you normally use first very often?

Edit 1: I have to correct myself. I finally found a way to get an "insecure" 4th menu item, but it worked. But I'm still able to reproduce the error, if the 1st menu item was created by a full custom context-menu.
So it must have something to do with the first initialization.

[ZOS_ChipHilseberg]

I looked into this and it's caused by the OnMouseUp closure being marked insecure if the control creation is triggered by an addon. I can pre-fill the pool with 10 controls so this isn't a problem anymore.

[Baertram]

There are several addons adding items to the context menus so I guess 10 items (standard ESO context menu items included or excluded?) wouldn't be enough.
FCOItemSaver alone is able to add 12 labels (if all settings are enabled for this addon) to the mouse context menu of inventory items!

Isn't there maybe anther solution that "really" fixes this, or did I understand you wrong?

[votan]

Originally Posted by Baertram There are several addons adding items to the context menus so I guess 10 items (standard ESO context menu items included or excluded?) wouldn't be enough. FCOItemSaver alone is able to add 12 labels (if all settings are enabled for this addon) to the mouse context menu of inventory items! Isn't there maybe anther solution that "really" fixes this, or did I understand you wrong?

Originally Posted by ZOS_ChipHilseberg I looked into this and it's caused by the OnMouseUp closure being marked insecure if the control creation is triggered by an addon. I can pre-fill the pool with 10 controls so this isn't a problem anymore.

Thank You very much, Chip. That would at least help. But is it the creation of the first control only? As I mentioned I was able to create a 4th "insecure" control, but "Destroy Item" (at 4th pos) did not raise an error?!?

The only solution I found to "really" fix that, (depending on how this marking works) is: Strictly separating the controls of build-in menuitems and custom menuitems: Using own control pools and introducing AddCustomMenuItem. Like in the attached file.
For us add-on developers it would just be an find-and-replace-all.

[sirinsidiator]

It should be okay if the entries are returned to the pool in the right order. Otherwise this will turn into a Russian roulette as soon as some addon adds an 11th entry.
A more permanent solution would be a separate pool and an AddCustomMenuItem function for addons. I haven't looked into the code too deeply though, so I could be wrong

edit: Well, seems that great minds thing alike

[DerBombo]

You guys seem to be pretty far ahead in this matter, but just to help reproduce this: On a hunch I disabled FCOItemSaver, because as Baertram said, it adds a bunch of menu items, and I didn't really come across this issue anymore. While adding support for FCOItemSaver to my own addon, I had to reactivate it for testing, and the issue was there again.

Just to make sure the issue is isolated correctly. I really like FCOItemSaver and would like to make use of it again.

[votan]

Originally Posted by DerBombo While adding support for FCOItemSaver to my own addon, I had to reactivate it for testing, and the issue was there again. Just to make sure the issue is isolated correctly. I really like FCOItemSaver and would like to make use of it again.

If you like to, try the attached lib of my previous post and replace all AddMenuItem with AddCustomMenuItem.
I did it for all addons I use on my own.
I don't know if it is worth to release this lib, because Chip said, they will pre-init the pool.

[DerBombo]

Originally Posted by votan If you like to, try the attached lib of my previous post and replace all AddMenuItem with AddCustomMenuItem. I did it for all addons I use on my own. I don't know if it is worth to release this lib, because Chip said, they will pre-init the pool.

Sure, I will give it a try. Though I'll be on vacation starting tomorrow, so I won't be posting any news before May 15.

[Baertram]

Thx for the update DerBombo, I'll check with Votan's librray as well to see if this helps.
(Unfortunately I never got this bug so far so I must see how I can reproduce it. Have to read this thread's posts all again )

EDIT:
I've prepared a version of FCOItemSaver with the libCustomMenu from Votan, you can download it here for testing.
Seems to work normally and I like the thing that the new custom made entries are located below the original ones!
https://dl.dropboxusercontent.com/u/...ver_0_6_4b.zip

[DerBombo]

That sounds great! Thanks! I'll give it a try as soon as possible. Could take some time though as I'll be on vacation, but I'm eager to test this!