浏览器差异 window.open
浏览器实现差异:
浏览器 | 无参数 | width,height | left,top | toolbar | location |
Directories
|
Status
|
Menubar |
Scrollbar
|
Resizable
|
screenX,screenY
|
FullScreen |
期待结果 | 有标签的 标签 无标签的 弹窗 |
尽量按指定 宽高弹窗 |
语义冲突的参数 相对parent页 left ,top位置 |
默认 无工具栏 yes 有工具栏 no 无工具栏 |
默认 有(r) yes 有(w) no 无 (r)只读,(w)可写 |
这玩意到底 是神马? 只有IE6支持 无期待结果 |
默认 无 yes 有 no 无 |
垃圾参数 无视. 只对早期 ie有效 |
默认auto yes auto no 无 |
默认 是 yes 是 no 否
|
真正语义上的参数 相对屏幕坐标 |
全屏显示 |
IE | 6 弹窗
7-8 弹窗 9 标签 |
全部 ok | (注1) | 全部
默认无 yes 有
no 无
|
6 默认 无 yes 有(w) (toolbar也有了) no 无
7,8,9 |
6 toolbar去掉 location部分 7,8,9不支持 |
6,7,8 无视参数 始终 有 9 |
全部 无视参数 始终 无 |
全部 默认 否 yes 是 no 否 |
不支持 | 全部 支持 |
|
Chrome | 全部 标签 | 全部 ok | 全部相对
父页面
left,top |
不支持此参数 弹窗木有工具栏 |
不支持此参数
始终有,且只读 |
不支持 | 无status bar | 1 无视参数 始终 无 2+ |
不支持此 参数,一律 可缩放 |
完全 ok | 不支持 | |
FireFox | 1, 1.5 弹窗
2.0+ 标签 |
全部 ok |
全部 |
默认无
yes 有
no 无 |
1, 1.5, 2 默认 无 yes 有(r) no 无 3+ |
不支持
|
无视参数 始终 有 |
无视参数
始终 无
|
2- 默认 否 yes 是 no 否 3+ |
完全 ok
|
3.6- 不支持 4 |
|
Safari | 3+ 弹窗 (Safari5 偏好设置 ,在标签中打开新 页面, 选项有-总是 ,永不,自动.默认是 永不.导致此问题.) |
3+ ok |
全部
left 相对父页面 (但当父窗体left的
位置导致新窗体不
能全部显示时,则
新窗体left,相对屏
幕为0,与ie7有些
相似)
top 相对屏幕
|
默认无
yes 有
no 无 |
默认 无 yes 有(w)(但 工具栏也有了) no 无 |
不支持
|
默认 无
yes 有 no 无 |
无视参数
始终 无
|
不支持此
参数,一律 可缩放 |
完全 ok
|
不支持
|
|
Opera | 9.2+ 弹窗 | 9.2 tab
9.6+
标签(有宽高,可拖
拽.但无法离开父
窗口)
|
9.6+
相对父页面
的left,top
9.2 标签
|
9.2 tab
9.6+ 因其本质 |
9.2 tab
9.6+ 因其本质
是tab所以无视 此参数.共享 location
|
不支持
|
9.2 tab
9.6+ 因其本质
是tab所以无视 此参数.共享 statusbar
|
无视参数
始终 无
|
不支持此
参数,一律 可缩放 |
不支持
|
不支持
|
|
360安全 | 3.3+ 标签
3.612 弹窗 |
3.612 弹窗(无视 宽高参数parent 页面多大新弹窗 就多大) 其他版本 标签 |
3.612 left top 和parent页面 有关,但位置算 法很混乱. 其他版本 标签
|
3.612 弹窗无视 一切参数.显示 一个完整窗口 其他版本 标签
|
.. | .. | .. | .. | .. | .. | .. | .. |
360高速 | 两种内核都 标签 | IE内核 标签
chromium都 ok |
chromium
同chrome
其他内核 标签
|
..
|
.. | .. | .. | .. | .. | .. | .. | .. |
搜狗高速 | 两种内核都 标签 |
两种内核都 标签
|
标签
|
.. | .. | .. | .. | .. | .. | .. | .. | .. |
TT | 标签 | 标签 |
标签
|
.. | .. | .. | .. | .. | .. | .. | .. | .. |
QQ5 | 两种内核都 标签 |
两种内核都 标签
|
标签
|
.. | .. | .. | .. | .. | .. | .. | .. | .. |
Maxthon2.5 | 标签 |
标签
|
标签
|
.. | .. | .. | .. | .. | .. | .. | .. | .. |
Maxthon3 | 两种内核都 标签 | 两种内核都 标签 |
标签
|
.. | .. | .. | .. | .. | .. | .. | .. | .. |
世界之窗 | 标签 |
标签
|
标签
|
.. | .. | .. | .. | .. | .. | .. | .. | .. |
MyIe | 标签 |
标签
|
标签
|
.. | .. | .. | .. | .. | .. | .. | .. | .. |
第二参数target(name)相关:
用途:
差异:
.IE下name的值为null 或 undefined时,行为与其他浏览器有差异. 等价于 'null' 或 'undefined' .在期望打开多个窗口,又想设置其他窗口参数时,参数设置此2值.会被视为有效的name值. (解决办法,使用 '' 空字符,或'_blank'代替 null 或 undefined. 建议用优先考虑空字符,因为某些浏览器的早期版本不支持 _blank)
.Opera,Chrome 下,如果一个iframe的id,与window.open的第二参数name同名.也具备同样效果. 其他浏览器则无此现象.
.Opera9.6+ ,如果在另一个iframe内调用其self.open的第二参数name与其他iframe的name或id同名,则仍然会重新打开一个窗口. 而不是去操作该iframe.其他浏览器则无此问题
IE7. left 相对的位置,总是相对非最大化时,父页的left+10px左右偏移.(就是非最大化时,显示在哪,最大化时,就显示在哪.但并不总是相对非最大化时的父窗口left,比如在父窗口left很靠右的情况下,则其会新窗口会变成相对屏幕来显示)
IE8. left,top全部相对屏幕
IE9. left 同IE6类似top 相对屏幕总是0
p3p 简洁策略及浏览器支持情况
从技术角度看,使 Web站点支持 P3P 是一个很容易的过程。但是,它要求网络运营商在审视数据处理方式时比以前更加仔细,并要求他们协调域内各个主机上的策略和处理方式。以下是如何使站点支持P3P 技术的具体步骤。
2. 分析 cookie 的使用情况以及您的站点上的第三方内容。
3. 确定要对整个站点应用一个P3P策略还是对站点的不同部分应用不同的P3P 策略。
4. 为站点创建一个或几个 P3P 策略。
5. 为站点创建一个策略引用文件。
6. 为 P3P 配置服务器。
7. 测试站点,以确定它确实支持 P3P。
● 用户是否可以查找该站点的数据库中保存了自己的哪些个人信息。
● 如何解决与站点之间有关隐私的纠纷(如客户服务台、隐私封印以及与隐私相关的法律等)。
● 所收集数据的种类。
● 所收集数据的使用方式,以及用户是否能选择接受或拒绝这些用途。
● 信息是否会被共享以及何时被共享,用户是否有选择的权力。
● 对所收集的用户信息进行定期清除的策略。
简洁策略对应的 HTTP Response Header :
compact-policy-field = `CP="` compact-policy `"`
compact-policy = compact-token *(" " compact-token)
compact-token = compact-access |
compact-disputes = "DSP"
compact-remedies = "COR" | "MON" | "LAW"
compact-non-identifiable = "NID"
compact-purpose = "CUR" | "ADM" [creq] | "DEV" [creq] | "TAI" [creq] |
"PSA" [creq] | "PSD" [creq] | "IVA" [creq] | "IVD" [creq] |
"PUB" [creq] | "OTR" [creq]
compact-category = "PHY" | "ONL" | "UNI" | "PUR" | "FIN" | "COM" |
"NAV" | "INT" | "DEM" | "CNT" | "STA" | "POL" |
我们常用的简洁策略的 P3P头为 - P3P : CP=CAO PSA OUR (其实, CP=. 就可以了.或者其他任何值都是可以的)分别对应了 :
compact-access(访问) : CAO - contact-and-other
compact-purpose(目的) : PSA - pseudo-analysis .这个就不放解释了,字面意思很明显, 目的就是做身份验证、分析
compact-recipient(受体) : OUR - ours
ps : 其他项就不列举,基于浏览器中只有IE支持.(chrome 部分支持).这一事实.深入研究没有必要. 如果你有兴趣,可以去相关链接查看文档.
对于众多提示性的反馈,是十分符合 P3P隐私策略的.即用户代理应该在恰当的时候,提醒用户.
已测知的问题:
IE6 第三方cookie 在有p3p头(使用p3p简介策略时) ,JS虽然有读写权限,但是在写的时候有个bug. 即,对于某第三方页面,如果是首次读到.其P3P头的话,则 js的写权限是没有的.必须要第二次访问到这个页面,且这个页面存在第三方cookie操作时,才允许JS写入Cookie.当然,读是一直没问题的.
if(Safari4或Safari5){var ifm = document.createElement('iframe');ifm.name ="postforcookie";ifm.src="about:blank";document.body.appendChild(ifm);var form = document.createElement('form');form.target = 'postforcookie';form.action = '//www.php.com/test.php';document.body.appendChild(form);Cookie.setCookie = function () {form.submit();}}
默认不禁止第三方cookie的浏览器测试:
浏览器 | 默认允许第三方Cookie | 是否支持P3P | 禁止第三方Cookie后,配置P3P简明策略头的效果 | 补充 |
IE6 | 否 | 是 |
HTTP可读写Cookie (第二次.直接Cache.也不行.除非第一次非Cache并读到p3p头.后面我会提到解决方案.) |
避免JS的写操作 |
IE7-IE9
|
否 | 是 | HTTP、JS,可随意读写. | - |
FireFox | 是 | 否 | HTTP、JS都不可读写 | - |
Chrome | 是 | 部分支持,趋势-否 | 趋势为HTTP、JS可读不可写. | - |
Safari | 否 | 否 | HTTP、JS可读不可写 | 借助Post提交表单,实现写操作. |
Opera | 是 |
否
|
JS可读写 HTTP可读不可写. |
- |
建议:
最后:
如果你非要用在ie6下,用js写cookie. 那么有一个很悲剧的做法.. 服务器端给资源配置可缓存.(包括反向代理和客户端.) 然后想办法在IE6的时候刷新一次页面.这样就ok了. 刷新时一定要用 location.reload(false) 即先忽略客户端缓存.尝试304服务器端校验客户端缓存可靠性..这样做的好处是.即保证了 cookie的写入性. 又保证,如果页面是静态资源.则反向代理的可用性.. 否则还是直接用动态资源,http方式去写好了. 需要注意的是.除了页面刷新.譬如其他方式加载页面资源.试图通过预读其p3p简介策略头.是无效的. 比如 用 script type="text/c" 方式去预读一次. 如果你有这个想法。还是早早放弃的好.