Three fixes addressing the reported 'auras silently vanish on next save'
bug, plus collateral robustness in the same code path:
1. WeakAuras.lua PLAYER_LOGIN handler (~L1297-1308): the downgrade branch
fired StaticPopup_Show('WEAKAURAS_CONFIRM_REPAIR', ...) synchronously
inside the event handler. On the CoA reworked StaticPopup system this
fires too early and silently fails to show the dialog, which means
neither OnAccept nor OnCancel ever runs, so Private.Login() is never
called. With no displays loaded, the next PLAYER_LOGOUT serializes an
empty table over WeakAurasSaved and the user loses all their auras.
Wrap the call in C_Timer.After(0, ...) so it fires after the event
frame stack has unwound and the popup system is ready.
This is the most likely root cause of the user report 'my auras don't
save anymore' that surfaced on the PTR last week.
2. WeakAuras.lua WEAKAURAS_CONFIRM_REPAIR popup (~L2263-2277): OnShow and
OnCancel both unconditionally dereferenced self.data.reason. If the
popup is ever fired with nil or malformed data this throws and blocks
Private.Login() from running via the OnCancel fallback. Guard with a
nil check and default reason to 'unknown' (treated as the automatic /
downgrade path, which is the safe default that still invokes Login).
3. Types.lua WeakAuras.class_types (~L1187): only populated from
CLASS_SORT_ORDER, which on CoA contains only the 11 vanilla classes.
The 21 custom CoA classes were silently missing from every class
filter dropdown in the options UI. Add a fallback loop over
LOCALIZED_CLASS_NAMES_MALE for anything CLASS_SORT_ORDER didn't
already register, mirroring the pattern the spec builder uses at
~L3829.
Florian Berthold
6078989cb1