061

BazWidgetDrawers

061 (2026-05-25)

Full Changelog Previous Releases

• v061: re-anchor adopted minimap buttons after click
  Some addons re-anchor their own LibDBIcon minimap button when the
  user activates them - VaultLoom is the case that surfaced this -
  which yanks the button out of the Minimap Buttons widget back
  onto the Minimap. Hook each adopted button's OnClick and schedule
  two cheap deferred re-layouts (at 0.05s and 0.30s) to re-assert
  ownership; the round trip is fast enough that the visual yank
  isn't perceptible.
  OnClick is the only safe surface for this. An earlier attempt to
  hook SetPoint/SetParent crashed the client by interacting badly
  with LibDBIcon's startup churn.
• default the MinimapButtons widget on with a curated widget order
  New installs now get the Minimap Buttons widget enabled out of the
  box, and the default drawer seeds a top-to-bottom widget order of
  Zone Text > Minimap > Minimap Buttons > Quest Tracker instead of
  falling back to alphabetical-by-id (which produced a less coherent
  layout). Existing profiles preserve any user-chosen order via the
  legacy widgetOrder migration.

060

BazWidgetDrawers

060 (2026-05-08)

Full Changelog Previous Releases

• v060: QuestTracker - shrink + pad the special-item icon
  The usable-item icon on a quest block was rendered at template-default
  size (26px) and centered on the title's vertical row. With a 18px-tall
  title the icon overflowed below into the description text and clipped
  the first wrapped line. The Blizzard ItemButton template's chrome
  (bevel + hover outline) is sized at template natural footprint, so
  calling SetSize alone shrank the icon texture but left the chrome at
  26 - making the visible button frame look bigger than the icon.
  Now the button is created at template-natural 26x26 and SetScale-d
  down to TITLE_HEIGHT (18) so chrome + icon shrink together. Anchored
  TOPRIGHT-to-title-TOPRIGHT with a small right-pad inset so it sits
  inside the block's chrome, and the first objective line carves out
  horizontal space (icon size + right pad + text gap) so the text
  doesn't run under it.
  Also fixes a related glitch: blocks are reused across quests, and
  the title text's narrowed RIGHT anchor wasn't being reset when a
  reused block landed on a quest with no special item, leaving the
  title artificially shortened.

v059

BazWidgetDrawers

v059 (2026-05-05)

Full Changelog Previous Releases

• v059: stop scrolling when everything already fits in the widget
• v058: Quest Tracker shows tracked recipes from the Professions panel
• Link License → GPL v2 page, Version → GitHub releases
• Link the WoW Midnight badge to the official Blizzard page
• Wrap 'Part of BazAddons' badge in link to bazaddons.com
• Add 'Part of BazAddons' badge + fix Version badge URL
  Link the addon to the suite via a shields.io badge (image-only so it
  renders cleanly on CurseForge too). Also corrects the Version badge
  URL from bazsec/ to BazAddons/ after the org reorg.

v058

BazWidgetDrawers

v058 (2026-05-05)

Full Changelog Previous Releases

• v058: Quest Tracker shows tracked recipes from the Professions panel

057

BazWidgetDrawers

057 (2026-05-04)

Full Changelog Previous Releases

• v057: tracker quest click opens map and quest log together
  The Quest Tracker widget's left-click on a quest title used to call
  WorldMapFrame:Show + QuestMapFrame_ShowQuestDetails directly, trying
  to bypass ShowUIPanel out of an old concern about BazMap's panel
  detachment. The bypass was incomplete: it never opened the QuestMap
  side panel itself, so clicking from a closed-map state showed only
  the bare map - quest title, detail body, and rewards were all
  missing. ShowQuestDetails alone sets DetailsFrame.questID and shows
  the details inner frame, but the surrounding QuestMapFrame stays
  hidden and the user thinks nothing happened.
  Now routes through QuestMapFrame_OpenToQuestDetails - the same entry
  point Blizzard's own objective tracker calls on a quest title click.
  ShowUIPanel on a UIPanelLayout-disabled WorldMapFrame is safe in
  modern BazMap (the panel-system path is short-circuited because the
  attribute is false), so the original avoidance no longer applies.
  The supertrack call before the open and the existing toggle-to-close
  path (clicking the currently-displayed quest closes the map) are
  preserved.

v056

BazWidgetDrawers

v056 (2026-05-03)

Full Changelog Previous Releases

• v056: user guide refresh
  Reorganise the in-game User Manual page, drop dev-y internal-mechanics
  text in favour of user-focused prose, add coverage for recently shipped
  features, match the new player-readable style across the suite.
• docs: refresh user guide
  • Reorganise pages for clearer top-down flow
  • Add coverage for recently-shipped features
  • Drop dev-y internal-mechanics text in favour of user-focused prose
  • Match the new player-readable style across the suite

v055

BazWidgetDrawers

v055 (2026-05-03)

Full Changelog Previous Releases

• v055: enabling a widget no longer auto-adds it to wildcard drawers
  Drawers can store widgets = "" (a "show all registered widgets"
  wildcard), used by the default drawer for new profiles. Previously,
  enabling a widget on the Widgets page would silently add it to every
  wildcard drawer because IsWidgetInDrawer treats "" as "yes always".
  That contradicts the explicit per-drawer toggle UX on the Drawers page.
  When SetWidgetEnabled transitions a widget from disabled -> enabled,
  materialise any wildcard drawers into explicit lists of currently-
  enabled widget IDs, EXCLUDING the just-enabled widget. So the new
  widget appears on the Drawers page with an unchecked toggle, and the
  user opts it in per drawer instead of getting it everywhere by default.
  Also rewrites CHANGELOG.md in player-readable style for CF release notes.

v054

BazWidgetDrawers

v054 (2026-05-03)

Full Changelog Previous Releases

• v054: WidgetHost:SetWidgetEnabled writes saved var for dormant widgets
  The function early-returned when GetDockableWidget(id) returned nil. That
  guard was meant to skip the live-side Show/Hide/Reflow path - but it also
  swallowed the addon:SetWidgetEnabled write, so toggling a dormant widget
  (LBW-registered, waiting on a condition) on the Widgets page never updated
  IsWidgetEnabled. Result: navigating to Drawers showed the widget still
  missing from the per-drawer list.
  Moved the saved-variable write to run unconditionally; the live branch
  (Show+Reflow vs DisableWidget) is now nested inside the widget-exists check.

053

BazWidgetDrawers

053 (2026-05-03)

Full Changelog Previous Releases

• BazWidgetDrawers v053 - Widgets list: recognise bazcore_ ID prefix. The user reported the BazCore CPU Monitor widget showing under 'Other' instead of 'BazCore' on the Widgets settings page. Settings.lua's source-detection falls back to matching the widget ID prefix when widget.source isn't explicitly set: bazdrawer_* > BazWidgetDrawers, bazwidgets_* > BazWidgets, bazbroker_* > LibDataBroker, anything else > Other. BazCore widgets use the bazcore_ prefix (e.g. bazcore_cpumonitor) which wasn't in the list. The companion BazCore v106 sets source = 'BazCore' explicitly on its RegisterWidget call so the issue is fixed for the immediate widget, but adding bazcore_ to BWD's prefix list here means any future BazCore widget that doesn't bother with the explicit source field still groups correctly. One-line addition to the elseif chain in BuildWidgetGroup, mirroring the existing patterns. No behaviour change for any other widget, bump to 053

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