Since last night, we've had some permanent failures of our plugin content policy unit tests. These are meant to prove that plugins are correctly blocked when viewing email. Viewing the tests running shows that the plugins are indeed NOT blocked for trunk/Daily builds. SUMMARY-UNEXPECTED-FAIL | test-plugins-policy.js | test-plugins-policy.js::test_3paneWindowDenied EXCEPTION: Plugin has not been blocked in message as expected at: test-plugins-policy.js line 155 addMsgToFolderAndCheckContent(false) test-plugins-policy.js 155 test_3paneWindowDenied() test-plugins-policy.js 186 frame.js 557 frame.js 626 frame.js 669 frame.js 497 frame.js 675 server.js 179 server.js 183 SUMMARY-PASS | test-plugins-policy.js::test_checkPluginsInNonMessageContent SUMMARY-UNEXPECTED-FAIL | test-plugins-policy.js | test-plugins-policy.js::test_3paneWindowDeniedAgain EXCEPTION: loadAllowed is not defined at: test-plugins-policy.js line 211 test_3paneWindowDeniedAgain() test-plugins-policy.js 211 frame.js 557 frame.js 626 frame.js 669 frame.js 497 frame.js 675 server.js 179 server.js 183 SUMMARY-UNEXPECTED-FAIL | test-plugins-policy.js | test-plugins-policy.js::test_checkStandaloneMessageWindowDenied EXCEPTION: Plugin has not been blocked in standalone window as expected at: test-plugins-policy.js line 175 checkStandaloneMessageWindow(false) test-plugins-policy.js 175 test_checkStandaloneMessageWindowDenied() test-plugins-policy.js 218 frame.js 557 frame.js 626 frame.js 669 frame.js 497 frame.js 675 server.js 179 server.js 183 This is definitely a mozilla-central change that has caused this, I'm currently trying to confirm the change that I think caused it.

Confirmed locally, bug 406541 caused the regression.

This followup patch to bug 406541 should've resolved this - the issue was NewURIWithDocumentCharset failing for mail:// URIs, and causing plugin's to have a NULL URI in some codepaths. https://hg.mozilla.org/mozilla-central/rev/b0b135e60d35