yes, i know this makes no sense but hear me out ok?

This is mainly useful for preventing unwanted side effects. Consider, for example, a WA which acts as a replacement for the players's cast bar. It might be reasonable to have such a WA unregister all events & hide the builtin cast bar in init action. The problem here is that if you open options and click on this WA to edit it, the init action will execute and disable the builtin cast bar, whether the user wants it to or not. Now, the author has suddenly created a landmine for their users, where every time they go to edit something, they might have to reload their ui to undo changes they explicitly asked not to happen.

Now, this is in principle avoidable today thru careful use of WeakAuras.IsOptionsOpen(), but honestly is kind of a headache. We could refuse to run any custom code on an unloaded aura, but this could have unwanted results for auras which /could/ load later in the session (eg in combat). So, it seems to me that we should inform the author when their code is running in "preview" mode, but isn't actually loaded.

Or, perhaps we should just tell authors to be more responsible with the code they write, idk.

Well, maybe OnLoad and OnUnload script handlers?

heh, this isn't the first time I've brought this up i see (#223), though at the time I was thinking of a different use case

@alexchopstix this ticket is not about auras visibility.

@alexchopstix this ticket is not about auras visibility.

Yes I know that. Nevermind I'm just deleting that comment because it's just going to confuse people. All of the answers for these types of issues all end up pointing to the creator of said WeakAura. And it's not like I don't disagree they should be making their WeakAuras with these things in mind but they don't. And I'm not gonna go create a whole custom WA myself when there's one out there, it's just that editing them is a pain in the ass.

Is what it is though.