Two 100012 Bugs

[circonian]

Chat Tab Overflow Bug:
See here for full details: Chat Window width & Tabs

Short Detais: Tabs are being placed in the overflow container area when it is not necessary.

The dimensions of the ZO_ChatSystem has a set width of 350 in xml and (as of 100012) the dimensions are not reset from the saved settings until after you call SharedChatContainer.LoadSettings(...). But that LoadSettings() is what (eventually) calls PerformLayout() which places tabs in the overflow area. So it thinks the controls width is still 350 because the saved setting dimensions have not been reset yet.

When you pulled the SetAnchor & SetDimension code out of SharedChatContainer.LoadSettings you reversed the order the code is called in.

Warning: Spoiler

function ChatContainer:LoadSettings(settings)
    -- These are now called in the wrong order
    -- As of 100012
    SharedChatContainer.LoadSettings(self, settings)
 
    self.control:ClearAnchors()
    self.control:SetAnchor(settings.point, nil, settings.relPoint, settings.x, settings.y)
    self.control:SetDimensions(settings.width, settings.height)
end
 
-- It should be
function ChatContainer:LoadSettings(settings)
    self.control:ClearAnchors()
    self.control:SetAnchor(settings.point, nil, settings.relPoint, settings.x, settings.y)
    self.control:SetDimensions(settings.width, settings.height)
 
    SharedChatContainer.LoadSettings(self, settings)
end

Chat Container Creation Bug:
See here for full details: CHAT ERROR SPAM

Short Details: Attempting to create chat containers for multiple chat windows causes errors. I know its not a finished/enabled feature, but they are errors that do not go away by reloading the UI, uninstalling an addon, or reinstalling (or so I was told, see post I linked, so I guess the NumChatContainers must be saved server side).

In the previous game version the CHAT_SYSTEM container.control child newWindowTab used to be defined in SharedChatSystem.xml and it was a child of ZO_ChatContainerTemplate. So when a new container was created (by the containerPool) using ZO_ChatContainerTemplate, the newWindowTab was there to grab. But newWindowTab has been moved to ChatSystem.xml and made a child of ZO_ChatWindow as of version 100012

So now when a new container is created (by the containerPool) using ZO_ChatContainerTemplate the newWindowTab child does not exist. ChatContainer:Initialize() attempts to grab the child newWindowTab (but it no longer exists for windows other than ZO_ChatWindow) and pass it to ZO_TabButton_Icon_Initialize which throws an error because self is nil (its supposed to be the container.control child newWindowTab). Therefore the container never gets created, but since the numChatContainers is saved in game code or server side reloading the ui or uninstalling an addon does not fix it.

If you want to simulate this error for testing you can just call:

AddChatContainer()
 
-- You don't even need to turn on:
CHAT_SYSTEM:SetAllowMultipleContainers(true)

While I'm at it, I might as well throw this out there. For new chat container controls created (not ZO_ChatWindow) the game does not properly anchor container.windowContainer, causing it & the container.currentBuffer to have dimensions 0,0.

[Baertram]

About the chat container creation bug:
If we simulate it, how are we able to "reset" the new container afterwards?
Or is the simulation not updating the server side container counter (as you guessed) and we are stuck with a new container we cannot remove?

[ZOS_ChipHilseberg]

Thanks for the detailed reports. We'll look into getting these fixed.

[circonian]

Originally Posted by Baertram About the chat container creation bug: If we simulate it, how are we able to "reset" the new container afterwards? Or is the simulation not updating the server side container counter (as you guessed) and we are stuck with a new container we cannot remove?

If you want to simulate it to play with it, it can be fixed by using this code:

local numContainers = GetNumChatContainers()
for i = numContainers, 2, -1 do
    RemoveChatContainer(i)
end

My main point about that bug was just that although multiple chat windows is not a finished or enabled feature and it would require an addon messing with stuff to create the problem, it is a serious bug (in my opinion) because it can only be fixed by code, the game cannot correct the problem itself.

Even though the solution (to stop the errors, not fix the problem) turned out to be quite simple, it still took me a while to track down what was causing it & find a solution. If someone accidently created that problem, then they would be stuck with the error & they would have no way of fixing it since uninstalling the addon, reloading the ui, or even reinstalling does not fix it. They would be forced to do what I did and track down the problem & find a way to fix it with code. Since I already did that I thought it was worth creating a post about it in case it happens to anyone else.

[circonian]

While testing a new version of my ChatIt addons multiple windows feature I found one more bug.

It is possible to transfer the main (first) window tab of the primary container to another container. It is also possible to transfer every window out of the primary container which really causes problems.

I do realize this sounds minor & highly unlikely...but it happened to me on accident, that's how I found it so I figure it could happen to someone else. Also since there are code checks to prevent transferring the 1st tab out of the primary container, it is obviously an unwanted feature so I thought I'de post this.

While testing my addon I was attempting to transfer several tab windows to another chat container. To make this easier I moved them very close to each other. When you drag a tab window if the mouse overlaps more than one TabDropArea, both controls get monitored by function

Warning: Spoiler

SharedChatContainer:MonitorTabMovement()
    local monitoredControl = self.monitoredControl
    
    local x, y = GetUIMousePosition()
    if Contains(x, y, GetTabDropArea(self.control, self.windows[1].tab)) then
        self.insertIndex = FindInsertPosition(self, monitoredControl, x)
        
        --peform a layout with extra space for the potential tab
        self:PerformLayout(self.insertIndex, monitoredControl:GetWidth())
    elseif self.insertIndex then
        --reset the layout
        self:PerformLayout()
        self.insertIndex = nil
    end
end

Since the tab drop areas are overlapping and that function uses GetUIMousePosition() both controls will pass the Contains(...) check and thus both containers get self.insertIndex set.
Then when you actually drop the tab, whichever container it goes into properly gets self.insertIndex set to nil, but the other container will still have self.insertIndex set to some value (what value is irrelevant).

If it dropped into the primary container and you then drag the 1st tab window from the primary container and drop it on top of the other containers TabDropArea (the other container still has self.insertIndex set so) it will transfer the tab to that container, even though it was the 1st tab window of the primary container because:

Warning: Spoiler

-- This function is called "OnMouseUp"
function SharedChatContainer:StopDraggingTab()
 
-- Which calls:
function SharedChatSystem:StopContainersTabDrop(initiator)
    local tabDropContainer
    for i, container in ipairs(self.containers) do
        if container ~= initiator then
            if not tabDropContainer and container:CanTakeTabDrop() then
                tabDropContainer = container
            end
            container:StopTabDrop()
        end
    end
    
    if tabDropContainer then
        --It's always the first window since that's the only draggable tab
        initiator:TransferWindow(1, tabDropContainer)
    end
end

container ~= initiator AND container:CanTakeTabDrop() will return true (because container still has self.insertIndex set to some value) then it will set tabDropContainer = container, then the TransferWindow code will run which will transfer the first tab window to the other container.

function SharedChatSystem:StopContainersTabDrop(initiator)
   ...
    -- It looks like it could use a primary check here:
    if not initiator:IsPrimary() then
        initiator:TransferWindow(1, tabDropContainer)
    end
   ...
end

and something to ensure all container.insertIndex values get wiped out on a tab drop.