Yeah, I've reported this bug myself. It's annoying, but fairly innocuous, and it's mostly a product of a design limitation. The net result is that the installer always launches the default system browser after installation is complete.
The installer technology employed here is generic across all of Adobe's free products. It doesn't know what browser you used to download the executable installer. At the point that it gets launched, the browser is already out of the equation.
You also can't make the assumption that because the user chose NPAPI, that you should launch Firefox (or Chrome for PPAPI), as there's a long tail of forks and related projects that implement those plugin interfaces.
Because the installers are necessarily cryptographically signed, you can't just slap in a configuration file on the fly (the signature validates both who distributed the code, and confirms that no bits in the file were changed after it was signed -- e.g. you know that it wasn't swapped out with malware as the bits travelled down the wire to you). This means that everything in the installer has to be pre-baked, so we can't just check the browser's user-agent string and then communicate that state to the installer by dropping a config file into it on the fly.
So, if you take that out to it's logical conclusion, the only really good option would be to serve up a distinct binary installer for each possible user-agent string, and then assume that the associated binary is in the default location when you try to launch it. You're talking thousands of possible combinations, all individually signed and hosted. This in turn becomes terabytes of data for each release, which has to be replicated across thousands of nodes on the CDN, and even then, you've still got a somewhat imperfect solution.
If the installer was launched from the browser (and you absolutely don't want the browser spawning installers on it's own for security reasons), then it would have the context about the appropriate parent process, and we could be way smarter about it.
So, given the complexity and the lack of a perfect solution, we make the compromise of using the default system browser. This allows us to ship the least number of binaries, which optimizes for CDN distribution and caching at ISP and organizational nodes (we're talking billions of monthly installs and a few dozen petabytes of pushed data), where thousands of individual variants would make all of that machinery useless.
If you're a novice user like my parents, you probably use a single browser, so the default option ends up being the right choice most of the time. For web developers and other power users that regularly use multiple browsers, the outcome is weird, but it's a skilled population and you're more than capable of understanding what happened and taking the right action. It's not the perfect outcome for 100% of users, but it's the least bad of the available options when viewed holistically.
4
Replies
AdChoices