In bug 1618094 we have a case where, due to flatpak, any request to externalProtocolHandlerExists returns trye, regardless of the protocol name. See https://searchfox.org/mozilla-central/rev/3c9369510cb883b9f08d5f9641e1233d2142f025/docshell/base/URIFixup.jsm#315-316 This means even a made up protocol like "bacon:" will end up trying to visit a non-existing url, instead of searching. We can implement a detection system that passes 2 randomly built strings to externalProtocolHandlerExists, and if those return true, we assume to be in "wildcard" mode and we stop trusting it. In those cases we can use HandlerService.exists() to check if the protocol is known internally, that would do a better job. A test should somehow mock externalProtocolHandlerExists to always return true and check we search for something like "bacon:tasty".
Bug 1744243 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
In bug 1618094 we have a case where, due to flatpak, any request to externalProtocolHandlerExists returns true, regardless of the protocol name. See https://searchfox.org/mozilla-central/rev/3c9369510cb883b9f08d5f9641e1233d2142f025/docshell/base/URIFixup.jsm#315-316 This means even a made up protocol like "bacon:" will end up trying to visit a non-existing url, instead of searching. We can implement a detection system that passes 2 randomly built strings to externalProtocolHandlerExists, and if those return true, we assume to be in "wildcard" mode and we stop trusting it. In those cases we can use HandlerService.exists() to check if the protocol is known internally, that would do a better job. A test should somehow mock externalProtocolHandlerExists to always return true and check we search for something like "bacon:tasty".