Copy/pasted from @freaktechnik 's comment in #187
I think we'll also have a big round of prompts with Bug 2024725 - add a custom scheme application handler for OAuth redirects.
- Scheduled for 152 tentatively
- Description of bug 2024725:
One problem to be aware of is that this will cause issues with systems that have multiple instances of Thunderbird installed—only one application can be associated with the protocol, so if it's associated with the user's copy of release Thunderbird, it will fail if they try to log in on their copy of beta. If all the relevant providers permit unlimited custom schemes, one possible way to mitigate this is by using distinct schemes for the different channels (thunderbird://, tb.beta://, tb.daily://, tb.build://, etc.), which would address the most common scenario, if not the underlying problem.
- The ability to open a system browser was added in 150 under the following Bug 2019793: add ability to use system browser for OAuth flow
- Comment 1:
By opening the OAuth login page in a browser, we can listen for a request and send the URI with parameters back to the normal flow on our end. This allows existing browser sessions to be usable as authentication, and enables passkey support on macOS for default localhost redirect targets (notably circumventing the conflict between Google's anti-custom redirect stance and macOS's callback design). The new behavior is behind a pref that is enabled for testing builds,but https redirect targets will continue to use the prior flow regardless.
Possible things to document
Copy/pasted from @freaktechnik 's comment in #187
One problem to be aware of is that this will cause issues with systems that have multiple instances of Thunderbird installed—only one application can be associated with the protocol, so if it's associated with the user's copy of release Thunderbird, it will fail if they try to log in on their copy of beta. If all the relevant providers permit unlimited custom schemes, one possible way to mitigate this is by using distinct schemes for the different channels (thunderbird://, tb.beta://, tb.daily://, tb.build://, etc.), which would address the most common scenario, if not the underlying problem.By opening the OAuth login page in a browser, we can listen for a request and send the URI with parameters back to the normal flow on our end. This allows existing browser sessions to be usable as authentication, and enables passkey support on macOS for default localhost redirect targets (notably circumventing the conflict between Google's anti-custom redirect stance and macOS's callback design). The new behavior is behind a pref that is enabled for testing builds,but https redirect targets will continue to use the prior flow regardless.Possible things to document