WowAce

What version of Grid2 are you using?

 r853-beta

What game client version (windows or mac) and language are you using ?

 Windows, english

What steps will reproduce the problem?

  Join a raid that has some members in it already
Did you try having Grid2 as the only enabled addon and everything else disabled?

  Yes

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

  Worked prior to 8.1

Do you have an error log of what happened? If you don't see any errors, make sure that error reporting is enabled (`/console scriptErrors 1`) or install [BugSack](https://mods.curse.com/addons/wow/BugSack).

  No error log

Please provide any additional information below.

 When you join a raid that already has members in it sometimes only a few members will be rendered. As soon as another person joins,leaves or is moved all the missing members appear.

At first sight it seems some bug in blizzard securetemplates code introduced in version 8.1 (because I have been able to reproduce the problem in other raid frames too), i will try to review securetemplates code to investigate if some some kind of workaround is possible.

Update, extra info about this issue for documentation purposes:

In patch 8.1 when unit information is not available yet, GetRaidRosterInfo() returns nil instead of "Unknown Entity" (for the name), and the blizzard SecureGroupHeaders code ignore these units instead of displaying them with the "Unknown Entity" name.

See  line 434 inside SecureGroupHeader_Update() function  in blizzard file "Interface\FrameXML\SecureGroupHeaders.lua"

Curiously UnitName() function returns "Unknown Entity" instead of nil.

SecureGroupHeaders.lua file cannot be modified, i don't know a good workaround to this problem, only to iterate all roster units to detect if some unit name is nil and a timer to force an update after some time, but this is ugly and cpu consuming.

Version 854 implements a workaround to this issue. It's not perfect, the real fix must by done by blizzard changing "Interface\FrameXML\SecureGroupHeaders.lua" code, or fixing GetRaidRosterInfo()  return values (returning "Unknown entity" instead of nil for unit names).

Could you use a local wrapper for GetRaidRosterInfo? Have it check for nil and return "Unknown entity" or does it normally return nil for raid slots that are not occupied?

Not possible, blizzard code is protected to prevent automatic gameplay addons, replacing an api function taints the code, and as soon as the protected code inside SecureGroupHeaders.lua calls GetRaidRosterInfo() while in combat,  the addon is blocked by the game.

I'm pretty sure GetRaidRosterInfo isn't a protected function, and even if it was, a wrapper function should be fine?

local function myraidroster(arg1)

local name, rank, subgroup, level, class, fileName,
zone, online, isDead, role, isML, combatRole = GetRaidRosterInfo(raidIndex);

if (name == nil) then

name = "Unknown entity"

end

return name, rank, subgroup, level, class, fileName,
zone, online, isDead, role, isML, combatRole 

end

But:

https://github.com/tomrus88/BlizzardInterfaceCode/blob/master/Interface/FrameXML/SecureGroupHeaders.lua

is secure code, if you replace the Global function GetRaidRosterInfo(), as soon as SecureGroupHeaders.lua code calls your custom function,  blizzard SecureGroupHeaders code becomes unsecure, then if you use the game raid interface (for example to move a player from one group to another while you are in combat) Blizzard_RaidUI\Blizzard_RaidUI.lua code becomes insecure too, and all will crash with errors like this:

11x [ADDON_ACTION_BLOCKED] AddOn "Grid2" tried to call the protected function 'RaidGroupButton1:SetPoint()'.

Because insecure code can not call protected functions while in combat. You can replicate the crashes simply typing into chat this simple code, that replaces GetRaidRosterInfo() :

/script local p = GetRaidRosterInfo; GetRaidRosterInfo = function(i) return p(i); end

Even ignoring the secure>insecure issue, there is another big problem: changing the behavior of a global function is not acceptable, because could crash another addons.