052

BazWidgetDrawers

052 (2026-05-03)

Full Changelog Previous Releases

• BazWidgetDrawers v052 - QuestTracker: ignore quest clicks during combat. The user reported ADDON_ACTION_BLOCKED for Button:SetPassThroughButtons() blamed on BazMap (and BazWidgetDrawers) when clicking a quest in the tracker during combat. The actual taint root is in BazMap - it intentionally calls SetAttribute on WorldMapFrame's UIPanelLayout-* attributes to disable Blizzard's panel layout management so the map can be freely positioned and scaled, and that taint propagates through the WorldMap and its child pins. Once tainted, any subsequent secure-restricted call on those frames during combat is blocked. The QuestTracker title click hander triggers Blizzard's QuestDataProvider:RefreshAllData via three different paths: (1) left-click on a quest calls C_SuperTrack.SetSuperTrackedQuestID which fires the EventRegistry Supertracking.OnChanged callback that QuestDataProvider listens to, (2) the same handler then opens WorldMapFrame and calls QuestMapFrame_ShowQuestDetails which can also trigger refresh, (3) right-click calls C_QuestLog.RemoveQuestWatch which fires QUEST_WATCH_LIST_CHANGED that QuestDataProvider also listens to. RefreshAllData walks every watched quest and calls AcquirePin -> CheckMouseButtonPassthrough -> SetPassThroughButtons on the pins; that last call is the protected operation that the taint blocks. The right fix isn't in BazMap (its taint source is unavoidable per its own comment block), it's in the tracker: don't trigger any of those refresh paths in combat, since they all fail and accomplish nothing. Wrapping the OnClick body in an InCombatLockdown() bail makes the click a no-op during combat, eliminating the error spam. The user can re-click after combat ends; right-click to remove a watch in combat is an unusual case anyway. Cosmetic-only refresh paths (block visuals updating from quest log events) keep working since they don't go through the secure SetPassThroughButtons path, bump to 052