26 - Incorrect height for cells with colspan

What steps will reproduce the problem?
1. Using :SetCell(...) with an column span > 1
2. Using long texts for the spanned cell and avoid using cells without column span > 1 will emphasize the effect
3. If the width of the spanned cell is less than the total with of unspanned cells in another line the effect can't be observed.

What is the expected output? What do you see instead?
When displayed the content is shown in a single line, but the height is much bigger than a single line would require.
Instead the height seems like what it would be like if the content had been wrapped around.

What version of the product are you using?
Appears in all revisions r136 and up.

Please provide any additional information below.

Release r136 replaced the width handling for colspans: function LayoutColspans(tooltip) with function FixCellSizes(tooltip).

I found that cell:getContentHeight() returned the same value after the resizing of the columns. This is because the actual cell width used in function getContentHeight() never got touched. As far as I can see it the cell size is nowhere set at all but the calculations depend on column width values alone.

So I think you either need to adjust the cell width values to their actual values so the fontstring width is set correctly so it returns the correct fontstring height.

Or (since the whole point of the resizing is to fit the content of the cell in one line) you just continue to recalculate the line height values with cell.fontstring:GetStringHeight():

function FixCellSizes(tooltip)

	for _, line in ipairs(lines) do
		if #(line.cells) > 0 then
			local lineheight = 0
			for _, cell in pairs(line.cells) do
				if cell and cell.fontstring then
					lineheight = max(lineheight, cell.fontstring:GetStringHeight())
			if lineheight > 0 then
				ResizeLine(tooltip, line, lineheight)
User When Change
Elkano Nov 11, 2010 at 09:44 UTC Changed assigned to from Torhal to Elkano
burny_dd Nov 03, 2010 at 12:16 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

  • Avatar of starlon starlon Jul 06, 2011 at 03:49 UTC - 0 likes

    I've been playing with this and it reminds me of an issue in LCD4WoW where fontstrings would expand in width as text characters scrolled from cell to cell. The solution to that was to set the maximum width per cell.

    I think this is simply a WoW UI bug. Even if it's not, I think the best route is to give users the ability to set maximum height. It's the best solution I can think of. I can't figure out why fs:GetHeight() is returning such a high number sometimes; the text never changes! I know I'm not as seasoned as other WoW addon authors around here, but after digging into this thing with everything I could think of I think this bug is an "infinite loop" reaching the same conclusion over and over; the only "break condition" I can see is in the user's option to restrict such spurious behavior. >.<

  • Avatar of starlon starlon Jul 06, 2011 at 02:15 UTC - 0 likes

    tooltip:UpdateScrolling() has a bad side effect when you're using SetPoint to move the tooltip around. In my particular case tooltip:GetTop() was returning nil, which is used in tooltip:UpdateScrolling().

  • Avatar of dhedbor dhedbor Nov 30, 2010 at 06:24 UTC - 0 likes

    Ok so I had this issue even without colspan and I figured out how to fix it. After setting up my tooltip a call like this fixes my layout problems:


    Perhaps this could be done automatically somehow, like on :Show() or :SmartAnchorTo() or both?

  • Avatar of dhedbor dhedbor Nov 21, 2010 at 21:39 UTC - 0 likes

    Everything appears to work ok if you also have individual columns with proper content. If, however, you only have colspan-enabled cells, things get all wonky.

  • Avatar of Elkano Elkano Nov 18, 2010 at 09:39 UTC - 0 likes

    Well, fontstring size is strange stuff :/
    see: (though that info could be outdated)

    In your testcase I think one of the problems is that the width of column 2-4 is defined by a colspan and not a single column but not sure... I'll try to run some more tests myself again...

    maybe go with only a topleft anchor for the fontstring or such...
    I still believe that the basic logic I implemented works fine meaning that you can only calculate the line height after you fixed the column width for colspans that don't have enough width, yet. Only the return values for the width/height functions seem to mess that up.

    Last edited Nov 18, 2010 by Elkano

    volunteer CurseForge moderator
    This posting is made of 100% recycled electrons.

  • Avatar of dhedbor dhedbor Nov 18, 2010 at 06:05 UTC - 0 likes

    Definitely seeing this issue myself. I'll try to set sizes specifically and see if that works.

  • Avatar of nebula169 nebula169 Nov 17, 2010 at 19:05 UTC - 0 likes

    Without setting maxWidth and minWidth on all of the columns, my tooltips tend to go batshit crazy

    Simple example:

    Any I wrong to think that a column should expand to its maxWidth without increasing the height and never be wider than its maxWidth? Could very well just be doing this wrong.

    Last edited Nov 17, 2010 by nebula169
  • Avatar of Elkano Elkano Nov 17, 2010 at 17:19 UTC - 0 likes

    I'm using it in ElkGuild with a maxWidth of 0 (at least local) and it's working fine :/

  • Avatar of nebula169 nebula169 Nov 17, 2010 at 14:35 UTC - 0 likes

    The problem is it is calculating for wrap that doesn't happen. GetStringHeight does account for wrapped lines, the reason the code above works (using fontString) is because the width isn't set.

    There's just something wonky with how LibQTip sets the width, because it's not corresponding to the width used in labelPrototype:SetupCell or labelPrototype:getContentHeight to get the font string height ;[ Even using maxWidth in :SetCell doesn't work properly.

    Last edited Nov 17, 2010 by nebula169: editing whore
  • Avatar of Elkano Elkano Nov 11, 2010 at 09:44 UTC - 0 likes

    I haven't looked into it in detail, yet, but the code you suggest has one major flow: it assumes that only the default cell provider is being used since it accesses internas of a cell that are assumed to be unknown to the library itself (even though the default cell provider is provided by the library).

    With regard to the cell width, this value is implicitly generated via the column frames the cell is anchored to. Actually I implemented that delayed recalculation of cell size to prevent the bug you describe since I had it without that code... strange...



Last updated
Mar 30, 2012
Nov 03, 2010
New - Issue has not had initial review yet.
Defect - A shortcoming, fault, or imperfection
Medium - Normal priority.

Reported by

Possible assignees