# Bug report: client XML parser silently drops addon frame definitions
## Summary
On the OctoWoW client, frames and regions defined in addon XML are not
reliably created. In the worst case, frames are created as Lua objects with
correct names, parents, sizes and positions, but are never attached to the
render tree — they never draw, and their parent's `GetChildren()` does not
return them. No Lua error is produced at any point, so the failure is silent
and looks like an addon bug rather than a client one.
This was found while getting the addon **CRAP** (Compact Raid and Party,
https://github.com/vargv666/CRAP) working, but nothing here is specific to
that addon. Any 1.12-era addon that defines frames or regions in XML can be
affected.
## Environment
- Server / client: OctoWoW
- Addon: CRAP, unmodified, downloaded fresh from the GitHub repo as a zip
- Reproduced across full client restarts, not just `/reload`
## Issue 1 (most severe): XML-created frames are not attached to the render tree
Member frames defined in the addon's `GroupFrame.xml` behave as follows:
- `getglobal('GroupFrameMemberFrame1')` returns a valid frame object
- `f:GetParent():GetName()` returns `GroupFrame` (the correct parent)
- `f:GetWidth()` / `f:GetHeight()` return the correct values (64 x 42)
- `f:GetLeft()` / `f:GetTop()` return sane on-screen coordinates
- `f:IsShown()` returns `1`
- **but** `f:IsVisible()` returns `nil` while the parent is visible
- **and** `GroupFrame:GetChildren()` returns **0 children**
- calling `f:Show()` explicitly does not make it render
- attaching a solid-colour texture to the frame renders nothing
The parent container itself is fine. A solid-colour texture attached directly
to `GroupFrame` renders correctly, so the container is real and visible.
Control test — creating an equivalent frame from Lua instead of XML works
correctly:
```lua
/run local f=CreateFrame('Frame',nil,GroupFrame) f:SetWidth(64) f:SetHeight(42) f:SetPoint('TOPLEFT',GroupFrame,'TOPLEFT',0,0) local t=f:CreateTexture(nil,'OVERLAY') t:SetAllPoints(f) t:SetTexture(0,1,0) f:Show()
```
That frame renders immediately, and `GroupFrame:GetChildren()` then returns 1.
So: Lua-created children attach and draw; XML-created children of the same
parent do not, despite reporting the correct parent from `GetParent()`.
Diagnostic used:
```lua
/run local n=0 for i,f in pairs({GroupFrame:GetChildren()}) do n=n+1 end DEFAULT_CHAT_FRAME:AddMessage('children:'..n)
```
```lua
/run local f=GroupFrameMemberFrame1 while f do DEFAULT_CHAT_FRAME:AddMessage(tostring(f:GetName())..' s:'..tostring(f:IsShown())..' v:'..tostring(f:IsVisible())) f=f:GetParent() end
```
## Issue 2: only the first `<Layer>` block of a template is processed
In a virtual template containing two `<Layer>` blocks, regions in the first
block are created and regions in the second are not.
With `<Layer level="OVERLAY">` first and `<Layer level="ARTWORK">` second:
- `GroupFrameMemberFrame1DebuffIndicator` (OVERLAY, first block) — created
- `GroupFrameMemberFrame1NameText` (ARTWORK, second block) — **nil**
- `GroupFrameMemberFrame1StatusText` (ARTWORK, second block) — **nil**
The missing regions are a mix of `FontString` and `Texture`, and the created
one is a `Texture`, so this does not appear to be about the region type. It
tracks with which `<Layer>` block the region is declared in.
## Issue 3: `<Frames>` nested inside a `StatusBar` is not processed
A `StatusBar` declared inside a template's `<Frames>` block is created
correctly, but a child frame declared inside *that* StatusBar's own `<Frames>`
block is not:
- `GroupFrameMemberFrame1HealthBar` (StatusBar) — created
- `GroupFrameMemberFrame1PowerBar` (StatusBar) — created
- `GroupFrameMemberFrame1HealthBarHealBar` (StatusBar nested inside HealthBar) — **nil**
This was still nil after reordering the XML so that `<BarTexture>` came after
`<Backdrop>` and `<Frames>`, so it does not appear to be an element-ordering
problem.
## Issue 4: `<Scripts>` handlers on XML frames appear not to be attached
The addon's drag handling (`OnDragStart` / `OnDragStop` on the container,
defined in `GroupFrame.xml`) did not function. Assigning the same handlers
from Lua with `SetScript` made dragging work immediately. This one is less
rigorously verified than the others, but is consistent with the pattern.
## Reproduction
1. Install CRAP unmodified from https://github.com/vargv666/CRAP
2. Log in, join a party
3. Run the diagnostics above
Expected: `GroupFrame:GetChildren()` returns 40, the member frames render.
Actual: 0 children, nothing renders, and the addon throws
`attempt to index local 'nametext' (a nil value)` at `core.lua:132` because
the `NameText` region from the second `<Layer>` block was never created.
## Impact
The Lua API reports success at every step — correct names, parents, sizes,
positions, `IsShown` true — while nothing renders and no error is raised.
That makes this extremely hard to attribute to the client. Anyone hitting it
will reasonably conclude the addon is broken.
Any 1.12 addon using multiple `<Layer>` blocks, nested `<Frames>`, or frames
defined in XML at all is potentially affected, so the blast radius is likely
much wider than this one addon.
## Workaround (for anyone else hitting this)
Rebuild the affected frames and regions in Lua with `CreateFrame`,
`CreateFontString` and `CreateTexture`, reusing the same global names the
addon's Lua code expects. Lua-created frames attach and render normally.
If this is of any help then great, if not then just skip over it
