Skip to content

fix: re-show objective tracker when hidden#1812

Open
johnson-christopher wants to merge 1 commit into
tukui-org:mainfrom
johnson-christopher:patch-1
Open

fix: re-show objective tracker when hidden#1812
johnson-christopher wants to merge 1 commit into
tukui-org:mainfrom
johnson-christopher:patch-1

Conversation

@johnson-christopher

@johnson-christopher johnson-christopher commented Mar 28, 2026

Copy link
Copy Markdown

When using AutoHide for boss fights, the objective tracker is sometimes being actually hidden, not just re-parented. When this happens, moving it back to the UIParent doesn't make it show again on its own. This fix explicitly calls Show to restore it.

To reproduce this issue engage a boss and observe that after the fight the objective frame doesn't come back.

The attached screenshot shows the debug status as well as some logging I added before and after the SetParent calls in the Collapse and Expand methods: WoWScrnShot_032826_105446

You can see that during the call to BL:ObjectiveTracker_Collapse, both before and after the call to re-parent the frame, the IsShown() API call returns true as expected. However, after the fight, when the AutoHider's state changes and its OnShow method eventually calls ObjectiveTracker_Expand, IsShown() now returns false. Because of that, even after you move it to the parent, IsVisible() is still also false and the frame doesn't show back up.

Ideally it would be nice to track down what is actually causing IsShown to return false on the frame and prevent it, but I can't find it anywhere. I'm hoping this workaround is good enough for now, or that my debugging provides some insight into how to better address the issue to someone more knowledgeable about it.

@kodewdle

Copy link
Copy Markdown
Member

calling show or hide will taint the objective tracker

@johnson-christopher

johnson-christopher commented Mar 29, 2026

Copy link
Copy Markdown
Author

calling show or hide will taint the objective tracker

I wish I could figure out what's making it go away in the first place. I have narrowed it down further. It happens when the contents of any objective change while the tracker is still hidden.

I was able to duplicate the issue with a small code change as such:

  1. Add [@target,exists] to the conditional that gets passed into RegisterStateDriver for the AutoHider.
  2. Turn on the Auto Hide feature.
  3. Start any WQ that requires you to kill stuff.
  4. Kill something.

After combat ends and you have no target the objective frame will stay gone. So it appears that any time some objective updates while the tracker is hidden causes the state of the frame to require more to reshow it that just reparenting it.

Note: It could also be something that's meant to periodically check the state of the objectives, rather than the changing of the values that does it, because I swear I saw it happen while killing trash in an instance with the [@target,exists] conditional included.

If you've got any ideas of things I could test further or areas to look at that are likely culprits let me know.

@johnson-christopher

johnson-christopher commented Mar 29, 2026

Copy link
Copy Markdown
Author

Ok, I found an even easier way to trigger it:

  1. Add [@target,exists] to the conditional that gets passed into RegisterStateDriver for the AutoHider.
  2. Turn on the Auto Hide feature.
  3. Target something to see the frame go away.
  4. Go to your quest log and toggle on or off any quest that you're tracking.
  5. Stop targeting something. The frame will not come back.

So it is definitely caused by something that's attempting to update the objective frame while it's hidden.

The objective tracker is sometimes being actually hidden by something, not just re-parented. When this happens moving it back to the UIParent doesn't make it show again on its own. This fix explicitly calls Show to restore it.
@johnson-christopher

Copy link
Copy Markdown
Author

I never found the root cause for this and now it's happening every time I return from being AFK as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants