WeakAuras

WeakAuras

206M Downloads

Icon not being properly dealt with by Masque

Foulbbqfeign opened this issue · 8 comments

commented

Describe the bug

Duplicated aura shows icon border in spite of supposedly being dealt with by Masque.

Do you have an error log of what happened?

No Errors.

To Reproduce

Created the issue by duplicating an aura in a dynamic group and the new aura having issues with borders/sizing after reloading my UI.

Screenshots

Upon duplicating aura:
image
After reloading UI:
image

Did you try having WeakAuras as the only enabled addon and everything else (especially something like ElvUI) disabled?

No. I was led to believe this was an issue with WA interaction with Masque.

Which version of WeakAuras are you using?

WA Version: 2.11.3
Masque Version: 8.0.1

Was it working in a previous version? If yes, which was the last good one?

It is an issue that has popped up intermittently in a bunch of different versions.

Additional context

WeakAuras.zip

This is the aura that is showing the issue right now: https://pastebin.com/Kvk7hfX3
The aura was created as a duplicate of this aura: https://pastebin.com/28NaZ5V1

HERE

commented

I can't reproduce that. I

  • imported your original aura.
  • put it into a dynamic group.
  • duplicated it
  • reloaded the ui.

And the aura was correctly skinned. Can you describe the exact steps to reproduce the problem?

commented
commented

@StormFX While investigating this, I've found a bug in Masque. I'm a unsure if it is the same one as Foulbbqfeign is seeing, but:

The simplest steps to reproduce that I can figure out are:

  • Have both Masque and WeakAuras installed.
  • Delete both Masque and WeakAuras settings
  • In WeakAuras create a new Icon
  • In the Masque settings select a different skin for the icon
  • Logout [1]
  • Login
  • The icon is now skinned with a Blizzard skin.

[1] After this step the settings file will contain:

  ["Groups"] = {
	 ["WeakAuras_new_2"] = {
		["SkinID"] = "Caith - No Shadow",
	},
	["WeakAuras"] = {
		["SkinID"] = "Caith - No Shadow",
	},
  },

Notably there's not a Inherit property in either the group nor the actual icon. Thus I believe that the Defaults for Inherit is used that is set in Masque:OnInitialize, which is true.

Thus on loading the settings, in Groups.lua Update for the WeakAuras Group, the Inherit code path is taking which then sets the skinId to the global masque setting, which is Blizzard.

And on loading the settings for WeakAuras_new_2, the same code path will set the skin of WeakAuras_new_2 to the Blizzard skin.

I think what is missing in the code is that on setting a Skin, the Inherit property must be set to false.

commented

@Foulbbqfeign I think while I've found a Masque bug while investigating this, that's unlikely to be the exact same bug as you are encountering. Thus can you do this:

  • Create a backup of your WeakAuras + Masque settings
  • Try reproducing the bug.

If you can reproduce the bug, I need that backup (I need the original settings!)
and clear instructions on what exactly I should do to reproduce it.

commented

The inherit code is only ever supposed to be run once per group per profile, when the group's saved data is first created. After the inheritance is done, the Inherit property is explicitly set to false. The problem may lie in the second condition of that line, which will not set the inherit property to false if the SkinIDs are the same, causing it to incorrectly inherit the parent's skin, even after the skin has changed.

I'll need to test it to make sure, but for the time being, try changing line 367 from:

if self.db.Inherit and self.db.SkinID ~= db.SkinID then

to

if self.db.Inherit then

And see if that fixes the issue. It may not be an issue of the setting of a skin needing to set the Inherit property to false, but ignoring the matching of the SkinIDs, since if it hasn't ever been inherited, it needs to inherit immediately and the never again on that group/profile.

To be clear, the inheritance should occur and then be disabled as soon as the group and its saved data is created for that profile, prior to any user interaction.

commented

Yes that does indeed fix the bug for me.

commented

I'll make sure to include this in the update.

commented

This has been dealt with at upstream.