Closed Meorawr closed 3 weeks ago
Сan't reproduce it in 10.1.5.50130 If I did everything right, of course
https://github.com/Stanzilla/WoWUIBugs/assets/1324849/aca73380-7ce2-45d3-acde-80dc472b6a85
I'm still able to reproduce it 10.1.5.50130.
I believe the issue you're having reproducing this is that you're on a non-English client; in some localizations the talent loadout commands like /loi
are fully localized without their English equivalents kept working:
https://www.townlong-yak.com/framexml/live/GlobalStrings.lua/GB#15684 https://www.townlong-yak.com/framexml/live/GlobalStrings.lua/RU#15684
If I change my client locale to French (for which /loi
is /ic
) the issue can't be reproduced unless I also update the macro to translate the command appropriately.
Yeah, you're right, sorry for bad information
Been a while, any update on this one?
Appears to be fixed in 10.2.7 and 1.15.3. Wasn't resolved in Cata, but I'd assume will be there in 4.4.1.
Addons that register slash commands can trigger a problematic interaction between the macro execution system and the talents interface resulting in action buttons becoming unusable via keybinds.
Test case
This issue only affects the Retail client. A video is attached demonstrating the issue, reproduced on a Restoration Shaman with Riptide, Ghost Wolf, and Earth Shield on the first three slots of the main action bar and the
/loi
macro described below as the last slot on the same bar. Note there is a pause in the video for a few seconds while a massive taint log gets written out.https://github.com/Stanzilla/WoWUIBugs/assets/287102/cc58f9eb-6f9b-44d5-b867-d7c54e2afb32
Preconditions
/loi
command used in the macro below appropriately.Steps
/run SlashCmdList.BREAKTHEUI = nop SLASH_BREAKTHEUI1 = "/breaktheui"
Explanation
When using any macro the chat system will attempt to import (via ChatFrame_ImportAllListsToHash) any newly defined slash commands present in the
SlashCmdList
global table to an internal hash table (hash_SlashCmdList
).Because we've registered a slash command and the first action we've taken with the chat system is to execute a macro this will pick up the taint from our pending command registration and propagates it through the remainder of the command execution.
This taint carries through into the execution of the class talent helper functions for switching the loadout index. This taints a significant amount of state owned by the talents UI - far too much stuff to list.
When hovering over the learned spell in the talent panel, a number of the previously tainted fields are read and taint execution. The interaction itself triggers a glow on the action button for the hovered spell, and with it this taints the
ON_BAR_HIGHLIGHT_MARKS
global.When changing the action bar page the action bar controller triggers a full update of all buttons on the bar. This reads the tainted
ON_BAR_HIGHLIGHT_MARKS
global, taints execution, and critically propagates this to the assignment of.action
fields (plus potentially more) on all subsequent action buttons that get updated on the same bar.When using a keybinding to activate the spell, the tainted
.action
field is read while updating flyouts which taints execution and leads to the UseAction call being blocked.Mitigations
A suitable fix would be to just band-aid the command import process with a securecall barrier as shown below. There's numerous call sites to ChatFrame_ImportAllListsToHash which can spuriously taint while processing pending command registrations. With this barrier the insertion into the
hash_SlashCmdList
table remains insecure, but the act of importing those commands doesn't taint random interactions with the chat system.Additionally, a similar barrier within ActionBarActionButtonMixin:UpdateSpellHighlightMark would be wise as there are other issues with the Talents interface in general that can trivially taint the
ON_BAR_HIGHLIGHT_MARKS
global - such as any addons calling the ClassTalentHelper functions. As this function is used purely for visual decoration, there should be no security risk with this change.