Fix unit frames disappearing when the group type changes in combat - #6
Open
KharchenkoDmitriy wants to merge 1 commit into
Open
Fix unit frames disappearing when the group type changes in combat#6KharchenkoDmitriy wants to merge 1 commit into
KharchenkoDmitriy wants to merge 1 commit into
Conversation
Solo/party/raid frames only applied their layout while the player was in that group type. Since F.UpdateLayout defers itself until combat ends, a frame group that had never been active since login - most commonly the party frame after a reload - was shown by its visibility driver with no sizes, anchors or header attributes when the group changed in combat, and stayed blank until combat ended. Once it had been laid out once, the same in-combat change worked, which is why this only reproduced the first time. Each frame group now lays itself out for the layout its own layoutAutoSwitch entry names (F.GetGroupTypeLayout) whenever it is not the active group type: full updates use that layout, partial updates from the Layouts tab apply when the edited layout is that one. The raid frame's combineGroups check reads the layout being applied instead of the current one. Picking a different layout for a non-active group type in the autoswitch dropdowns re-lays that frame group out right away. Classic only, like the visibility-driver change it builds on: the Retail branch of the group frames keeps its old behavior and never reaches this. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YngV4VgYFwrPdgvWYVz7p
KharchenkoDmitriy
force-pushed
the
fix/combat-frame-visibility
branch
from
September 1, 2026 05:44
ac65c9b to
2254124
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.
Keep all three drivers registered at all times and let the secure conditional resolve the switch natively:
Deciding whether a frame group must stay hidden now has to be possible for a group type the player is not currently in, which the active layoutGroupType alone cannot answer. PreUpdateLayout therefore records the layoutAutoSwitch entry that applies to each frame group for the current zone (in a pvp instance all three use the battleground/arena entry), and F.IsGroupTypeHidden reads that mapping. This also fixes battleground/arena "hide" settings being ignored, which a per-frame group-type lookup would otherwise have missed.
Applied to all flavors: Core.lua, Core_Cata.lua, Core_Mists.lua, Core_Vanilla.lua (also used by TBC) and Core_Wrath.lua.