Those different versions of the browser use different versions of the safe_client_libs underneath, therefore the authorisation response URI are encoded differently and not compatible.
E.g. let’s say the authenticator uses safe_client_libs v0.X.0 to generate the authorisation response, so if the app receiving it also uses the same version of the safe_client_libs, i.e. v0.X.0, it will be able to decode it. But if the app is using a different version of the safe_client_libs it will throw a serialisation error when it tries to decode the URI and won’t be able to connect to the network.
I’m not sure which version of the apps and/or safe_client_libs you are using against those three different versions of the browser, e.g. you need latest versions of the example apps to use browser v0.8.0 as they won’t work with previous versions due to this incompatibility in the encoding.
Now, this is something eventually we’ll need to support somehow, i.e. have some backward compatibility with the encoding we use for the URI to allow the users to upgrade their browser even when the encoding changed and be able to authorise apps which were using older versions of the safe_client_libs. For the moment this is not the case and you need to make sure you use compatible versions.
I hope I’m explaining myself here and it’s not too confusing, otherwise please don’t hesitate to ask.
One minor comment, note that the authorisation pop-up is not to switch apps, each time you get the pop-up is an independent action which allows you to either authorise or deny permissions to the app, but you could have all apps you have authorised running in parallel, even after closing the browser.