Conversation
Bug: Issue: When the Quest Tracker is hidden (combat/raid visibility rules, or mouseover mode while idle), it still receives mouse clicks. Reported during a Mythic Twin Fangs pull: clicking to target an add where the (invisible) tracker sits instead opened the quest log and pinged the map, and the click never reached the world. Reproduces reliably against a target dummy in Silvermoon while just "Hide in Combat" is set. A live GetMouseFoci() capture confirmed the actual clickable element is an anonymous pooled button several levels inside CampaignQuestObjectiveTracker, not the tracker's own top-level frame. Fix: ObjectiveTrackerFrame is EditMode-managed, so Hide()/Show() are combat-protected, and every hide path in this file (raid/arena auto-hide's combat fallback, the general user-visibility toggle, and mouseover idle) used SetAlpha(0) instead -- alpha never affects mouse interaction, and EnableMouse never cascades to child frames either, so a deeply nested quest-line button stayed fully clickable while the whole tracker looked invisible. Added SetTrackerHidden, which reparents the tracker under an already-Hidden container frame -- this drops visibility AND mouse for the entire subtree (children included) without walking any of them, matching this file's own stated design rule. SetParent is not part of the EditMode Hide()/Show() combat protection, so this now runs in combat too; it is pcall-guarded with a fallback to the old top-level-only SetAlpha/EnableMouse behavior in case that assumption ever proves wrong. Every hide/show site in the file (raid/arena auto-hide, the general visibility toggle, and the mouseover hover-reveal) now goes through this one helper.
Bug: Issue: PR CI's "Locale keys up to date" check failed on this branch, but unrelated to its actual change -- upstream/main's own committed EllesmereUILocales/_keys.txt already had a stale header count (791) that did not match its own real key count (800); the key list content itself was already correct, only the printed comment was wrong. Fix: ran .tools/extract-locale-keys.sh and committed the corrected count, per the CI job's own remedy instructions. No functional change.
svart2521
force-pushed
the
quest-tracker-clickable-when-hidden
branch
from
September 17, 2026 10:39
c59905d to
af1747d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug: https://discord.com/channels/585577383847788554/1549935368550481992
Issue: When the Quest Tracker is hidden (combat/raid visibility rules, or mouseover mode while idle), it still receives mouse clicks. Reported during a Mythic Twin Fangs pull: clicking to target an add where the (invisible) tracker sits instead opened the quest log and pinged the map, and the click never reached the world. Reproduces reliably against a target dummy in Silvermoon while just "Hide in Combat" is set. A live GetMouseFoci() capture confirmed the actual clickable element is an anonymous pooled button several levels inside CampaignQuestObjectiveTracker, not the tracker's own top-level frame.
Fix: ObjectiveTrackerFrame is EditMode-managed, so Hide()/Show() are combat-protected, and every hide path in this file (raid/arena auto-hide's combat fallback, the general user-visibility toggle, and mouseover idle) used SetAlpha(0) instead -- alpha never affects mouse interaction, and EnableMouse never cascades to child frames either, so a deeply nested quest-line button stayed fully clickable while the whole tracker looked invisible. Added SetTrackerHidden, which reparents the tracker under an already-Hidden container frame -- this drops visibility AND mouse for the entire subtree (children included) without walking any of them, matching this file's own stated design rule. SetParent is not part of the EditMode Hide()/Show() combat protection, so this now runs in combat too; it is pcall-guarded with a fallback to the old top-level-only SetAlpha/EnableMouse behavior in case that assumption ever proves wrong. Every hide/show site in the file (raid/arena auto-hide, the general visibility toggle, and the mouseover hover-reveal) now goes through this one helper.