I've only recently noticed because until now we've had no mochitests that require displaying mail. (We have other test suites.)

There's some leads here I can follow. I'm pretty sure we're at least getting to the loadURI but beyond that I don't know. This stuff is well outside my areas of expertise so I was hoping somebody out there had a simple answer. ;-)

GL

On 28/08/19 22:23, Gijs Kruitbosch wrote:
On 26/08/2019 23:40, Geoff Lankow wrote:
Hi

Over the past year or so, I've been adding mochitests for new Thunderbird features. It's recently occurred to me that in a mochitest, Thunderbird does not display mail messages. Not even the message header list, just a blank rectangle where the message should be.

How long has this been the case? You mentioned "it's recently occurred to me", but it's not clear from your message if this has been happening for years or if it's only started relatively recently.

And do the mochitests still pass even though nothing loads? That'd be a bit surprising if the loadURI call fails (and probably something to address)...

Obviously this is quite important as displaying messages is Thunderbird's primary function. But I don't understand the reason.

I expect that it has something to do with message URLs, which are of the form mailbox:///path/to/mailbox?number=1234.

I know that mochitest does things to network access to prevent tests from accessing the internet, but that doesn't seem to be the reason as I can load the URL using fetch.

Have you actually verified that the document is not loading in the mochitest, rather than loading and not being painted/rendered? That'd be the first thing to check.

Is there some logic in docshell that behaves differently in a test?

Almost certainly yes, also for debug vs. opt, but I'm not sure which specific bits would be interfering here...

As far as I can work out, this code [1] is a part of the loading process, and if docShell->LoadURI fails that would explain why nothing further happens. (IANA core hacker, excuse my ignorance!)

Are you able to use try...catch on the loadURI call to see if it throws an error (assuming the load is initiated from JS) and/or use a native code debugger (msvs' devenv, gdb, lldb, whatever) to investigate what's causing that error? That seems the best way to investigate this further, especially if you don't have a regression range for when this started happening...

~ Gijs


GL

[1] https://searchfox.org/comm-central/rev/753e6d9df9d7b9a989d735b01c8b280eef388bab/mailnews/local/src/nsMailboxService.cpp#205

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to