If this is a regression that can be pinned on particular change set, I would guess this: https://phabricator.services.mozilla.com/D161656 This moved the call to ```processHeaders()``` out of the mime emitter code and into ```onStateChange()```. Maybe when it was in mime emitter as soon as the headers are streamed they are displayed. (Headers are first in the stream.) With ```processHeader``` in ```onStateChange()``` in ```msgHdrView.js``` the whole message has to be streamed (from imap, pop3, webserver, disk cache or offline store) before the headers appear so there can a significant delay as is being reported.
Bug 1851871 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
If this is a regression that can be pinned on particular change set, I would guess this: https://phabricator.services.mozilla.com/D161656 This moved the call to ```processHeaders()``` out of the mime emitter code and into ```onStateChange()```. Maybe when it was in mime emitter as soon as the headers are streamed they are displayed. (Headers are first in the stream.) With ```processHeader``` in ```onStateChange()``` in ```msgHdrView.js``` the whole message has to be streamed (from imap, pop3, webserver, disk cache or offline store) before the headers appear so there can a significant delay as is being reported. The change https://hg.mozilla.org/comm-central/rev/8689605fa4c8901006b16e50aaa5e4d9bf6ce700 was pushed on 1-19-2023. After this the problem occurs. Before this the problem doesn't occur.
If this is a regression that can be pinned on particular change set, I would guess this: https://phabricator.services.mozilla.com/D161656 in bug Bug 1799764. This moved the call to ```processHeaders()``` out of the mime emitter code and into ```onStateChange()```. Maybe when it was in mime emitter as soon as the headers are streamed they are displayed. (Headers are first in the stream.) With ```processHeader``` in ```onStateChange()``` in ```msgHdrView.js``` the whole message has to be streamed (from imap, pop3, webserver, disk cache or offline store) before the headers appear so there can a significant delay as is being reported and observed. The change https://hg.mozilla.org/comm-central/rev/8689605fa4c8901006b16e50aaa5e4d9bf6ce700 was pushed on 1-19-2023. After this the problem occurs. Before this the problem doesn't occur.
If this is a regression that can be pinned on particular change set, I would guess this: https://phabricator.services.mozilla.com/D161656 in bug Bug 1799764. This moved the call to ```processHeaders()``` out of the mime emitter code and into ```onStateChange()```. Maybe when it was in mime emitter as soon as the headers are streamed they are displayed. (Headers are first in the stream.) With ```processHeader``` in ```onStateChange()``` in ```msgHdrView.js``` the whole message has to be streamed (from imap, pop3, webserver, disk cache or offline store) before the headers appear so there can a significant delay as is being reported and observed. BenC wrote this in his review of the patch. Maybe he is referring to current issue?: >I don't like how the population of the header/attachment data occurs at the moment, but thats more a factor of how the Mime stuff happens right now. I think the population aspect could be changed in future without affecting users of the nsIMailChannel, so it's not too big a deal. The change https://hg.mozilla.org/comm-central/rev/8689605fa4c8901006b16e50aaa5e4d9bf6ce700 was pushed on 1-19-2023 along with many other changesets. After this the problem occurs. Before this the problem doesn't occur.
If this is a regression that can be pinned on particular change set, I would guess this: https://phabricator.services.mozilla.com/D161656 in bug Bug 1799764. This moved the call to ```processHeaders()``` out of the mime emitter code and into ```onStateChange()```. Maybe when it was in mime emitter as soon as the headers are streamed they are displayed. (Headers are first in the stream.) With ```processHeader``` in ```onStateChange()``` in ```msgHdrView.js``` the whole message has to be streamed (from imap, pop3, webserver, disk cache or offline store) before the headers appear so there can be a significant delay as is being reported and observed. BenC wrote this in his review of the patch. Maybe he is referring to current issue?: >I don't like how the population of the header/attachment data occurs at the moment, but thats more a factor of how the Mime stuff happens right now. I think the population aspect could be changed in future without affecting users of the nsIMailChannel, so it's not too big a deal. The change https://hg.mozilla.org/comm-central/rev/8689605fa4c8901006b16e50aaa5e4d9bf6ce700 was pushed on 1-19-2023 along with many other changesets. After this the problem occurs. Before this the problem doesn't occur.