Just a drive-by thought, without having digged into this problem: The patch from that bug is probably too big for uplift to mozilla-esr102, and it also had regression bugs. Adalbert's comment 29 suggests one specific code block to be related. You could test a build that removes this one block (red) from mozilla-esr102. Maybe that code block could be slightly improved to keep the header if the origin is non-null. (In other words, only suppress if origin is null). If that indeed works without other regressions for Thunderbird, you could ask for that change on mozilla-esr102 with #ifdef THUNDERBIRD
Bug 1810760 Comment 30 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Just a drive-by thought, without having digged into this problem: The patch from that bug is probably too big for uplift to mozilla-esr102, and it also had regression bugs. Adalbert's comment 29 suggests one specific code block to be related. You could test a build that removes this one block (red) from mozilla-esr102. Maybe that code block could be slightly improved to keep the header if the origin is non-null. (In other words, only suppress if origin is null). If that indeed works without other regressions for Thunderbird, you could ask for that change on mozilla-esr102 with ```#ifdef MOZ_THUNDERBIRD```
Just a drive-by thought, without having dug into this problem: The patch from that bug is probably too big for uplift to mozilla-esr102, and it also had regression bugs. Adalbert's comment 29 suggests one specific code block to be related. You could test a build that removes this one block (red) from mozilla-esr102. Maybe that code block could be slightly improved to keep the header if the origin is non-null. (In other words, only suppress if origin is null). If that indeed works without other regressions for Thunderbird, you could ask for that change on mozilla-esr102 with ```#ifdef MOZ_THUNDERBIRD```