overture

-rendered list items available. The limits I found: • Firefox: ignores declarations that resolve to a value higher than 17,895,697 pixels (which is a bit more than 2²⁴). • IE: ignores declarations that resolve to a value equal to or higher than 10,737,418.23 pixels (2³⁰ − 1 hundredth pixels). • WebKit: clamps values somewhere around 2²⁵ (~33,554,432) pixels; clamping means you don’t need to worry about it so much, since that was the best workaround in other browsers anyway. And so we ended up with the workaround code at https://github.com/fastmail/overture/blob/41cdf36f3e7c8f0dd1... (the Firefox check was of much older vintage, I just added the IE case). (Nowadays, the IE part is gone again because IE is gone, hooray!) So yeah, it actually only took about 200,000 messages in the list to hit this limit and fall over, or subsequently just make the bottom of the mailbox inaccessible. 200,000 messages in one mailbox is uncommon, but not at all unrealistic, especially in an “All mail” sort of mailbox. For those in this thread saying “why would you ever want to do that?”: this is why. Real scrolling is extremely useful in small cases, and still absolutely useful on occasion as things grow even extraordinarily large. This is not a degenerate case: this is very sane. And pagination of any form would be horrible. Like pagination basically just makes old emails inaccessible except by precise search in Gmail. Fastmail’s approach is very, very strongly desirable here. Pagination is the clumsy hack, not progressive loading of a list (though I will admit that you need list items to be of consistent heights to do a good job of this style of progressive loading).

ons will be imprecise and you’ll have to make messy adjustments from time to time. Overall it generally won’t be too bad so long as there’s not too much variation in them, but it’s definitely still inferior. You can then read the full subject line and other truncated fields either by opening the email, or by hovering, as the full text is set as the tooltip. And here’s a general tip for others: if you do ever automatically truncate overflowing text, you should set the element’s tooltip to the full text. —⁂— ¹ Browser do have limits on how large you can make containers, and handle excess in different ways. IE had the lowest threshold of failure at around ten million pixels, beyond which point it would ignore values; the workaround I implemented in https://github.com/fastmail/overture/commit/8d01c74d8c5d4ae0... came as a direct result of a customer reporting that scrolling was broken in IE in their mailbox with a couple of hundred thousand emails. Firefox breaks a little after 2²⁴ pixels, also ignoring values, so it’s still covered in https://github.com/fastmail/overture/blob/0c9828a5b77ad14383... (note the IE stuff is gone because IE is dead! :-) ). WebKit-heritage browsers accept larger values, but clamp them to about 2²⁵ pixels. In all cases, the clamping solution means you can’t access the emails at the end of the list. C’est la vie.

where near that tall, capping effective values much earlier, with the consequence that you can’t access things near the end of the list. But the problem was that once you get much larger still, it starts ignoring the values you specify altogether, which would break the entire technique.) For us, the most common height of each email’s entry in the list is 51px; at that, 400,000 emails is enough to get to 20,400,000px high, which is enough to break both IE and Firefox (not sure about Chrome or Safari, I’ve never actually tested it; their failure mode may well just be different, limiting numbers instead of ignoring them). 400,000 emails in a mailbox isn’t all that common, but it does happen.