Some links that should result in the iTunes application being opened do not work on Nightly. I hit the bug on Mac Nightly 66 and did not test other platforms. Expected result: On the itunes.apple.com pages such as <https://itunes.apple.com/us/movie/moana-2016/id1175204079>, clicking on the button "View in iTunes" should result in a prompt to open the iTunes application. If the user clicks through the prompt, the iTunes application should be opened. Actual result: Clicking on the "View in iTunes" button has no effect and the prompt is not displayed. mozregression indicates the fix for bug 1459264 or bug 167475 introduced the problem: 17:13.29 INFO: Last good revision: 2ee2f297c4106e017231ed67fba4034d766c942b 17:13.29 INFO: First bad revision: c4bf214bd2e65e460fcd24a6483635c1d5cb4771 17:13.29 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2ee2f297c4106e017231ed67fba4034d766c942b&tochange=c4bf214bd2e65e460fcd24a6483635c1d5cb4771

This happens because itunes.apple.com creates an iframe and it sets its location to be: "itmss://itunes.apple.com/us/movie/something" I would suggest to relax the blocking of external protocol URLs in <iframe> allowing just the first one via PopupBlocker.

Comment on attachment 9034122 [details] [diff] [review] iframe_external.patch a test would be really nice

Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/ebee49cf0270 Allow just the first external protocol URL in <iframe>, r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/9dfb6ebdf897 Expose PopupBlocker status via ChromeUtils, r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/e6f6dc496d61 Expose PopupBlocker status via ChromeUtils - tests, r=smaug

https://hg.mozilla.org/mozilla-central/rev/ebee49cf0270 https://hg.mozilla.org/mozilla-central/rev/9dfb6ebdf897 https://hg.mozilla.org/mozilla-central/rev/e6f6dc496d61