User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Steps to reproduce:
- Create a browser extension with a browser action
- Generate redirect URL for extension and output to console
- Create a new app for some service that allows OAuth2 authentication.
- Add URL as a valid redirect URL for some service that allows OAuth2 authentication (I was using LinkedIn)
- Add Client secret/Client ID to background script for use by launchWebAuthFlow()
- Add a background script listening for clicks on a browserAction
- When click on toolbar button, run a content script that adds a button to the current tab. (This step is unnecessary but I did it to simulate how my actual plugin is working)
- When button is clicked, send a message to the background script to perform authentication
- Use launchWebAuthFlow() to launch OAuth2 authentication, e.g.
const redirectUrl = browser.identity.getRedirectURL(),
url = 'https://www.linkedin.com/oauth/v2/authorization?'
+ '&redirect_uri=' + encodeURIComponent(redirectUrl)
Authentication window pops up just fine and I am able to authenticate with the external service (LinkedIn). When the external service redirects back to the redirect_uri, the status bar shows activity - first it says "Waiting for linkedin...." and after about another 60s it shows "Connecting to 12341234.extensions.allizom.org..." and finally after about another 60s, the browser window finally closes and the promise is resolved successfully.
After authenticating successfully with the provider, the redirect back to the extension should be near immediate. The window should close and the promise should be resolved or rejected. It should not take 2+ minutes for this process. The same exact plugin works fantastic in Chrome.
I also tried this entire setup with the google-userinfo sample plugin and it does the same thing. The promise eventually resolves successfully and the extension is able to then get an access token and display my user info but it takes several minutes.
I have attached a zip of a sample plugin I wrote to show the problem. I used the exact same plugin in both Chrome and FF and it works great in Chrome but not in FF.
I also attached a full networking trace from about:networking. In this trace, I clicked the "Allow" button in the web auth window with LinkedIn (where the 2+ minutes starts) around 19:55. I am no expert in reading these traces but you will notice that it seems that what it is taking forever to do is resolve the 6b58f8236c5fabbc2af9a2329831c9e097dce470.extensions.allizom.org hostname with DNS. It does the following several times:
2019-02-16 19:57:53.566004 UTC - [Parent 59553: Socket Thread]: D/nsHostResolver Adding address to blacklist for host [6b58f8236c5fabbc2af9a2329831c9e097dce470.extensions.allizom.org], host record [0x135bf2160].used trr=0
2019-02-16 19:57:53.566020 UTC - [Parent 59553: Socket Thread]: D/nsHostResolver Successfully adding address [126.96.36.199] to blacklist for host [6b58f8236c5fabbc2af9a2329831c9e097dce470.extensions.allizom.org].
2019-02-16 19:57:53.566039 UTC - [Parent 59553: Socket Thread]: D/nsSocketTransport nsSocketInputStream::OnSocketReady [this=0x124002a88 cond=804b000e]
2019-02-16 19:57:53.566054 UTC - [Parent 59553: Socket Thread]: D/nsSocketTransport nsSocketOutputStream::OnSocketReady [this=0x124002ac0 cond=804b000e]
This final time above is right around when the window finally closes and the promise is resolved.