Here's what Neil wrote on the internal bug tracker, about 2 months ago: --- It's actually quite easy to crash Thunderbird by calling registerProtocolHandler. The problem is that this API is designed for browsers, which means that it assumes that various protocols such as nntp aren't in use. If a web page tries to call registerProtocolHandler passing in nntp as a parameter then it will immediately crash. The crash dumps don't have enough information to tell me what code is calling registerProtocolHandler but it's certainly not Owl. In particular, none of the protocol handlers that Owl registers are allowed by registerProtocolHandler, so it can't even contribute to the crash that way either. The crash is not in code provided by Owl or even executed by Owl, since there are [over 120 crashes where Owl wasn't even installed](https://crash-stats.mozilla.org/signature/?addons=%21~owl%40beonex.com&signature=mozilla%3A%3Adom%3A%3ANavigator%3A%3ACheckProtocolHandlerAllowed&date=%3E%3D2021-01-01T00%3A00%3A00.000Z&date=%3C2021-12-01T00%3A00%3A00.000Z). --- Most of the crashes are right after startup. I suspect that some of the Office365 or Duo (or other third party MFA providers) or Exchange login pages of the server contains a JavaScript call to `registerProtocolHandler()` in the HTML login page. Owl just happens to open that login page, which is where the correlation comes from, but we cannot avoid the login page. But aside from that, it seems that Owl is in no way triggering this nor causing this. For the same reason, I have no idea how we could possibly work around this. The only way out that I see is to change RyanVM's mind and to backport bug 1717833 to 78 ESR. Other ideas? (I have yet to confirm the above thoery and to find a minimal test case that triggers the crash at will.)
Bug 1717042 Comment 26 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Here's what Neil wrote on the internal bug tracker, about 2 months ago: - It's actually quite easy to crash Thunderbird by calling registerProtocolHandler. The problem is that this API is designed for browsers, which means that it assumes that various protocols such as nntp aren't in use. If a web page tries to call registerProtocolHandler passing in nntp as a parameter then it will immediately crash. The crash dumps don't have enough information to tell me what code is calling registerProtocolHandler but it's certainly not Owl. In particular, none of the protocol handlers that Owl registers are allowed by registerProtocolHandler, so it can't even contribute to the crash that way either. The crash is not in code provided by Owl or even executed by Owl, since there are [over 120 crashes where Owl wasn't even installed](https://crash-stats.mozilla.org/signature/?addons=%21~owl%40beonex.com&signature=mozilla%3A%3Adom%3A%3ANavigator%3A%3ACheckProtocolHandlerAllowed&date=%3E%3D2021-01-01T00%3A00%3A00.000Z&date=%3C2021-12-01T00%3A00%3A00.000Z). - Most of the crashes are right after startup. I suspect that some of the Office365 or Duo (or other third party MFA providers) or Exchange login pages of the server contains a JavaScript call to `registerProtocolHandler()` in the HTML login page. Owl just happens to open that login page, which is where the correlation comes from, but we cannot avoid the login page. But aside from that, it seems that Owl is in no way triggering this nor causing this. For the same reason, I have no idea how we could possibly work around this. The only way out that I see is to change RyanVM's mind and to backport bug 1717833 to 78 ESR. Other ideas? (I have yet to confirm the above thoery and to find a minimal test case that triggers the crash at will.)
Here's what Neil wrote on the internal bug tracker, about 2 months ago: ~~ It's actually quite easy to crash Thunderbird by calling registerProtocolHandler. The problem is that this API is designed for browsers, which means that it assumes that various protocols such as nntp aren't in use. If a web page tries to call registerProtocolHandler passing in nntp as a parameter then it will immediately crash. The crash dumps don't have enough information to tell me what code is calling registerProtocolHandler but it's certainly not Owl. In particular, none of the protocol handlers that Owl registers are allowed by registerProtocolHandler, so it can't even contribute to the crash that way either. The crash is not in code provided by Owl or even executed by Owl, since there are [over 120 crashes where Owl wasn't even installed](https://crash-stats.mozilla.org/signature/?addons=%21~owl%40beonex.com&signature=mozilla%3A%3Adom%3A%3ANavigator%3A%3ACheckProtocolHandlerAllowed&date=%3E%3D2021-01-01T00%3A00%3A00.000Z&date=%3C2021-12-01T00%3A00%3A00.000Z). ~~ Most of the crashes are right after startup. I suspect that some of the Office365 or Duo (or other third party MFA providers) or Exchange login pages of the server contains a JavaScript call to `registerProtocolHandler()` in the HTML login page. Owl just happens to open that login page, which is where the correlation comes from, but we cannot avoid the login page. But aside from that, it seems that Owl is in no way triggering this nor causing this. For the same reason, I have no idea how we could possibly work around this. The only way out that I see is to change RyanVM's mind and to backport bug 1717833 to 78 ESR. Other ideas? (I have yet to confirm the above thoery and to find a minimal test case that triggers the crash at will.)