There are many different scenarios of when to block a toplevel data: URI navigation. We should think about all those again and explicitly write test cases of what should be allowed and what shouldn't. Out of the top of my head I can think of: Blocked: * window.open("data: [including that new window doesn't get openend] * window.location = "data: * toplevel redirects to data: Allowed: * user typing data: into the address bar * downloading a data: URI * save-link-as of data: URI Please note that we already have some tests here: * browser_test_toplevel_data_navigations.js * test_block_toplevel_data_navigation.html

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #0) > Allowed: > * user typing data: into the address bar > * downloading a data: URI > * save-link-as of data: URI I think there is also no need to block data: images.

As long as "images" is defined to exclude image/svg+xml, I agree on data: images.

With all the different bugs for this project (see dependencies of Bug 1380959) we also landed individual tests for all the different scenarios. Please see: * test_block_toplevel_data_navigation.html * test_block_toplevel_data_img_navigation.html * test_allow_opening_data_pdf.html * browser_test_toplevel_data_navigations.js All these tests cover: * window.open("data" * window.location = data: * <a href="data:" * meta refresh to data: * redirects to data: * loading data:image/png as well as blocking data:image/svg+xml * loading of data:application/pdf. * loading of data: using a CodeBasePrincipal as well as loading using a SystemPrincipal All these tests essentially rendered this bug to become a WONTFIX.