(In reply to Ben Campbell from comment #1)
Bug 1562158 would have been my first suspect too.
But looking through the code, I can't see anything obviously borked there.
I can't get that line to assert when I run the
composition/test-send-button.js mozmill test locally (see below for the asserts I do get)
The assert occurs when the number of selected items we get from the selection ranges of a nsITreeSelection differs from the
This could happen if:
- the nsITreeSelection has elements selected which are out of the view's range (ie non-existent elements)
- the nsITreeSelection is returning overlapping ranges.
My money is on 1. The nsTreeSelection implementation code aims to cope with merging overlapping ranges and it looks solid. I'm sure it's been well exercised over the years. I think overlapping ranges would have been noticed before. The implementation has a couple of oddities, but overall looks good.
I think things are being selected outside the view. Maybe something's being deleted and the selection hasn't been updated accordingly...
Anyway, I've just added a bunch of asserts for a try run to catch both 1 and 2 above:
The asserts I do get on
[36909, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /fast/ben/tb/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 760
[36909, Main Thread] ###!!! ASSERTION: didn't subtract all that we added: '(space == 0 || space == nscoord_MAX) && ((l2t == FLEX_PCT_LARGE) ? (-0.001f < basis.f && basis.f < 0.001f) : (basis.c == 0 || basis.c == nscoord_MAX))', file /fast/ben/tb/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 987
Could conceivably be masking things. I haven't dug into these in detail, but from experience I've noticed treeview widgets tend to use table layouts... so it could be the same bug manifesting differently.
My observation in bug 1158471 comment 6
is related to case (1) above.
Basically, I observed that
- selection count is misused a little bit.
It stands for different numbers in different places.
In some places, it seems it stands (?) for the selected lines as in selection of message headers in the header pane. If you select, say, 30 headers, then this should be 30.
However, in some places, this number seems to be used for
the lines that are currently *visible* in, say, header pane and selected.
So even if we may have selected 30 header lines as a whole, suppose the header pane shows only
10 headers, only 10 selected lines can be shown at maximum,
and if we scroll the headers, fewer selected lines are visible depending on the position of selected lines and where we look at the headers through the header pane.
No wonder assertion failures occur (!)
Good to know that someone has finally paid attention to this Assertion.
The last observation was done manually: you select some header lines in message list.
Shrink the message list window, or scroll back and forth.
Voila. You get assertions with DEBUG BUILD.