![Thunderbird logo](https://assets-prod.sumo.prod.webservices.mozgcp.net/media/uploads/products/2024-02-12-07-36-53-599028_1.png)
Will Bug 1355350 be fixed in Thunderbird 52 ESR?
In Bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=1355350 I see:
Tracking Flags: Tracking Status thunderbird_esr52 + affected thunderbird53 --- wontfix thunderbird54 --- fixed thunderbird55 --- fixed
As I'm not that familiar with the Mozilla bug tracking process I wonder what that means for ESR users. Will the fix will find its way into ESR release 52 eventually? What might be the expected timeframe?
Ŋuɖoɖo si wotia
> Will the fix will find its way into ESR release 52 eventually? Yes. It is our hope that it will be in the next point release. But that is dependent on the patch first going through beta.
> What might be the expected timeframe? 2-3 weeks. We hoped it would be sooner, but currently we are having trouble getting the beta built.
Please post again on Monday and we may have a better idea.
Xle ŋuɖoɖo sia le goya me 👍 0All Replies (3)
It looks like there's no decision yet. But there's only preferences' changes in this patch, you could do it by yourself:
Workaround: Set preference browser.cache.memory.max_entry_size to the value of -1 (unlimited) and create integer preference browser.cache.memory.capacity with the value of 200000 (200 MB, 25 MB per message).
That's not the patch I'm interested in. (1355350-lift-entry-size.patch) There are two other patches (1355350-delay-concurrent-read.patch and 1355350-doom-on-inteterrupted.patch (sic!)) that actually fix the bug(s).
Ɖɔɖɔɖo si wotia
> Will the fix will find its way into ESR release 52 eventually? Yes. It is our hope that it will be in the next point release. But that is dependent on the patch first going through beta.
> What might be the expected timeframe? 2-3 weeks. We hoped it would be sooner, but currently we are having trouble getting the beta built.
Please post again on Monday and we may have a better idea.