众所周知，如果打算做一个纯前端的下载CSV的功能，可以使用如下代码。
let content = "test,test1\nabc,123";
let blob = new Blob([content], { type: 'text/csv' });
let csvUrl = URL.createObjectURL(blob);
let elementLink = document.createElement('a');
elementLink.href = csvUrl;
elementLink.target = '_blank';
elementLink.download = 'test.csv';
elementLink.click();
在DOM中新建了临时的a标签，并执行点击动作。之后就会把content的内容作为csv文件下载下来。
无论是在VF里还是Lightning Component中皆可使用。
在VF页面中嵌入这段代码之后，使用Chrome在Classic与Lex下使用都是正常的。
但是使用Firefox在Classic下正常，在Lex下却会报错失败。
比如在我的实验环境，错误信息为如下。
Content Security Policy: The page’s settings blocked the loading of a resource at blob:https://snrenv2-dev-ed–c.ap4.visual.force.com/016d4701-1e33-47a1-8099-eaec82c7ff1d (“frame-src”).
唔。。。Content Security Policy。（关于什么是CSP，可以参考阮一峰老师的文章或者MDN文档（什么是内容安全策略，CSP用法）。
而且是来自于frame-src的CSP设定。
那么就一定存在iframe。
还记得在Classic时代，VF页面的主域名和标准页面的主域名是不同的。
VF：https://snrenv2-dev-ed–c.ap4.visual.force.com/
非VF：https://snrenv2-dev-ed.my.salesforce.com/
Lightning时代可能为了解决这个问题，在Lex的时候，居然将VF嵌套进了iframe里？？？
这样的话，让我们来看看Salesforce的CSP是怎么设定的。F12->网络->respones header。
Content-Security-Policy:
default-src ‘self’; script-src ‘self’ ‘nonce-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’ chrome-extension: ‘unsafe-inline’ ‘unsafe-eval’ *.canary.lwc.dev *.ap4.visual.force.com https://ssl.gstatic.com/accessibility/; object-src ‘self’ https://snrenv2-dev-ed–c.ap4.content.force.com; style-src ‘self’ blob: chrome-extension: ‘unsafe-inline’ *.ap4.visual.force.com https://snrenv2-dev-ed–c.ap4.content.force.com; img-src ‘self’ http: https: data: blob: *.ap4.visual.force.com; media-src ‘self’ *.ap4.visual.force.com https://snrenv2-dev-ed–c.ap4.content.force.com blob:; frame-ancestors ‘self’; frame-src https: mailto: *.ap4.visual.force.com; font-src ‘self’ https: data: *.ap4.visual.force.com; connect-src ‘self’ https://api.bluetail.salesforce.com https://staging.bluetail.salesforce.com https://preprod.bluetail.salesforce.com *.ap4.visual.force.com https://snrenv2-dev-ed–c.ap4.content.force.com https://ap4.salesforce.com
可以看到针对iframe的设定是允许https, mailto, vf域名。这明明vf域名是合法的啊。
按照最上面的写法，最后生成的url是blob:https://snrenv2-dev-ed–c.ap4.visual.force.com/016d4701-1e33-47a1-8099-eaec82c7ff1d，甚至将https://snrenv2-dev-ed–c.ap4.visual.force.com/016d4701-1e33-47a1-8099-eaec82c7ff1d直接拷贝到浏览器地址栏可以看到csv内容本身。那么为什么Firefox就根据CSP拦截了，而Chrome却没有拦截呢?
其实互联网的世界，并不是那么风平浪静。
以前在一篇文章里谈到过，计算机的世界其实并不是精确如一尘不染的实验室，而是建立在一系列没那么精确，不那么清晰，不是很靠谱的机制上。能跑就行。
虽然对于各种互联网协议的定义都有专门的组织去管理去发展。但是就如法律条文，协议与规范写的再精确也难免因为理解偏差而出现南辕北辙的情况。
而且从当年微软的IE带头不遵守规范伊始，各家浏览器的兼容性问题就始终困扰着广大开发者。就像你规定了IE，Firefox，Chrome都必须戴帽子出门，但是你会发现IE把帽子戴膝盖上了，Firefox斜着戴，Chrome反着戴——————谁让你没规定怎么戴。
这里关于CSP如何拦截我推测也是类似的情况（查阅浏览器代码实在力不从心），Chrome觉得blob: + 合法域名 = 合法，而Firefox觉得blob: 没有在名单里 = 不合法。
所以为了解决这个问题，我们只能干掉Firefox。我们只能绕开CSP，这是一种自己hack自己的行为，也许在某次Firefox更新或者salesforce更新之后就失效了。慎用。
如果说，VF所在的iFrame收到主页面的CSP策略约束，那么，我在iFrame中再造一个iFrame，外层iFrame没有设定CSP，在我造的iFrame里就可以为所欲为了。
代码如下
let iframe = document.createElement('iframe');
document.body.append(iframe);
iframe.style.display = 'none';
iframe.addEventListener('load', ()=> {
let content = "test,test1\nabc,123";
let blob = new Blob([content], { type: 'text/csv' });
let csvUrl = URL.createObjectURL(blob);
let elementLink = document.createElement('a');
elementLink.href = csvUrl;
elementLink.target = '_blank';
elementLink.download = 'test.csv';
elementLink.click();
});
原理为，凭空捏造一个iFrame嵌到当前iFrame，然后监听load事件，将下载CSV的代码放入其中。这样当iFrame创建好了之后就会自动开始下载。
慎用。。。慎用。。。慎用