2007-03-09

Transfer Arguments with showModelessDialog and window.open

The document of showModelessDialog on MSDN said:

Because a modeless dialog box can include a URL to a resource in a different domain, do not pass information through the vArguments parameter that the user might consider private. The vArguments parameter can be referenced within the modeless dialog box using the dialogArguments property of the window object.

But, again, MS lies. showModelessDialog can't pass arguments to a different domain . If you open a dialog in a diff domain, window.dialogArguments of the dialog will be undefined (even dialogArguments is a literal string).

In fact, because dialogArguments could be an javascript object, there would be a security issue if such transfer is allowed.

To create a return value for showModelessDialog, set the vArguments parameter to a callback function or an object in the showModelessDialog call. In the modeless dialog box, you can reference this function or object through the dialogArguments property of the window object.

Imagine your site has a dialog use such callback method descripted above. But the hacker can easily get the name of the callback function from the source code of the dialog page. If cross domain access is allowed, the hacker could write his own page, provide his evil callback via dialogArguments and open your dialog page. Then he can publish his troy page in somewhere and fish your customers. If the users open his page, the best case would be leaking some info (but maybe password, if it's a login dialog), and in the worst case, the evil code is executed, hacker can do everything, such as transfer the user's money to his account (if it's a bank site).

Thanks to God, the hackers are disappointed because MS lied in their documents :P

BTW, I found some changes from IE6 to IE7. It is summarized in the below table. The similar functionality(window.open with dependent feature) in FF and Opera also tested here.

same domainsame domain with diff portdiff domain
showModelessDialog (IE6)YNN
showModelessDialog (IE7)YYN
window.open (Firefox2)YNN
window.open (Opera9)YYN

For showModelessDialog, Y means the script in the dialog window can get dialogArguments.

For window.open, Y means the script in new window can access the variables which the parent window assigned to dialog window object. Code sample:

page1
=====
var newWin = window.open(page2, features);
newWin.abc = {toString:function(){return 'abc'}}

page2
=====
alert(window.abc); // return 'abc'

At last, IE have a timer issue. Code sample:

page1
=====
var newWin = window.showModelessDialog(page2, args, features);
newWin.abc = {toString:function(){return 'abc'}}

page2
=====
alert(window.abc); // return 'abc' when first access, otherwise undefined

window.onload = function () {

  alert(window.abc); // return 'abc' when first access, otherwise undefined

  setTimeout(function () {
    alert(window.abc); // return 'abc'
  }, 10);

}

Apparently, this issue is related to the cache issue of the showModelessDialog. If the page is loaded from the cache, all scripts in the page1 will executed before the second line of the page2 unless it is deferred by a timer.

2007-03-07

Shame IE7 break backward compatibilty on showModelessDialog and showModalDialog

Please read Why Does IE Resize My Dialogs written by Travis, the program manager for Trident/OM. And more importantly, read the comments of this article.

Golad is totally right, and the arguments oppose him are feeble. MS IE team shouldn't, needn't change the meanings of dialogWidth/dialogHeight. Just introduce two new property (innerWidth/innerHeight is good name which Mozilla and Opera use for such case) is fine!

Ironically, it is said:

IE7 no longer provides a method for script to retrieve the dialog’s frame dimensions ('chrome' area included). This was formerly available through window.dialogHeight/Width, which now returns the content area. Future versions of IE may provide this functionality.

Does Travis try to tell us IE8 will introduce outerHeight/outerWidth(or any other names, who care?) which just have the same meaning as dialogHeight/dialogWidth before IE7? Ridiculously!! Why not leave dialogHeight/dialogWidth away, and introduce innerHeight/innerWidth?

Someone said it's good because it fix the past mistake, but I say no! The past mistake can never be fixed, because we will still face the users who use the past system. The worst thing is, this 'fix' corrupt our patch(eg. check offsetHeight/offsetWidth to adjust the dialog size) for the original mistake!!! We have had to pay for MS mistake once. Now we have to pay for it twice!!

But now, everything is too late. They, the team in the richest software company, ignored the right opinions, and released IE7 with such mistake, and we, web developers, are compelled to write tons of version-specific hack. Damn!

It's not the first time MS break the backward compatibility. See Ridiculous 'Backward Compatibility' by M$ (written in Chinese) for a example about JavaScript.

BTW, this behavior change of dialog also introduce a new bug (tested under Vista RTM). Call showModelessDialog(url, args, 'resizable:yes;dialogWidth:320px;dialogHeight:480px') to open a simplest page which only one line:

<!DOCTYPE html>

This line means the page should render in standard mode. Then resize the dialog, u will see the scrollbar will occurs if the window size is smaller than original size. If u add some contents in the page, u will see the viewport(the 'initial containing block' in css term) of the page is never resize!!

At first, I thought it may be by design for IE7, but after I found that the behavior of quirk mode is same as IE6, I soon realized that it's not a feature but a bug which IE dev team and QA team all missed. Shame MS again! No one tested any standard mode page in a resizable dialog?

It costs me two hours to get a workaround. I'll post it later.

2007-02-17

Happy New Year

Note: This artical is written in Chinese.


又是一年春来到,愿新年行财运,肥猪拱门,财源茂盛。

2007-02-06

Mozilla Bug 314874 Fixed

15 months ago, I submitted this bug. I'm very glad to see it is finally solved.

2007-01-29

A boring MSDN webcast

Note: This artical is written in Chinese.


今天看了微软开发合作部的“互联网策略资深顾问”王洪超主讲的MSDN webcast《Gadget开发简述》视频。老实说,整个讲座技术含量很低,基本上是浪费我的时间。

技术含量低,可能因为这是一项较新的技术,也资料匮乏(Gadget参考是我看到过的最差的MSDN文档),且老王估计不是这方面专长,又或者是其讲座受众本身定位就是很低……

老王的口齿不清,这是先天不足,也罢了。但是,整个讲座废话连篇,演讲水准也超差,就令我对老王这个MVP甚感失望。倒是那个黄继佳配合的还算ok。也许老王本身就口才较差,专长技术……问题是这个讲座又毫无技术含量。

相比较而言,Microsoft UK的Developer & Platform Group的Deniel Moth所做的Vista:Sidebar Gadgets视频讲演,虽然也相当简单,但至少step by step的条理清楚。

BTW,指出老王的两个问题:

第一,他代码中创建xmlhttprequest的方式不好。首先应该利用IE7的native xmlhttprequest支持,而不是创建ActiveX控件XMLHTTP;其次读取xml dom直接用responseXML属性即可,读取requestText来创建XMLDOM完全是画蛇添足。

第二,他说调试困难。这说明他对Gadget的开发经验不足(当然,也拜微软糟糕的文档所赐)。因为有System.Debug.outputString方法,所以log基本没有问题。而且修改刷新也不需要关闭sidebar,只需要reload即可(虽然由于微软的bug,不能直接调用location.reload,但是可以用location.href = location.href的trick)。

2007-01-26

About OEM deployment of Vista Sidebar Gadget

Note: This artical is written in Chinese.


关于gadget的安装,目前总结有以下几种安装方式:

  1. 直接复制到用户目录下(%LOCALAPPDATA%\Microsoft\Windows Sidebar\Gadgets\),这种方式下,只有该用户可以看到该gadget。根据我的同事的试验,这种方式存在一个潜在的问题:如果安装程序请求了管理员权限,可能取得的用户目录将不是该用户的目录,而是该管理员的目录,这导致该用户无法看到该gadget。
  2. 打包成.gadget后,本地运行,会以对话框提示用户该gadget的来源和数字签名等信息,询问是否安装,这种方式的优点是,会直接安装到用户的运行列表中,而不像其他方式那样还需要用户自行加入sidebar,安装后的目录同第一种方式。
  3. 复制到共享gadget目录下(%ProgramFiles%\Windows Sidebar\Shared Gadgets),这种方式估计是微软指定的安放OEM所带gadget的方式,所有用户都可以看到gadget,但有两个缺点,一个是用户删除该gadget后,并没有真正删除该gadget,而是放入了SkipList中,该用户以后将无法看到该gadget,重新安装也没有用,只有关闭sidebar进程后修改配置文件才行但可到sidebar属性中选择“恢复Windows自带小工具”来恢复;另一个是用户没有共享gadget目录下的写权限,gadget程序的功能受到了一定限制(具体还需要更多测试)。

上述3种方式各有特点也各存在一些问题,我还会做进一步的测试,找到一个最佳方式。

1月28日更新:

可通过以下命令行指令修改权限:

icacls "%ProgramFiles%\Windows Sidebar\Shared Gadgets\MyGadget" /grant Users:(F)
icacls "%ProgramFiles%\Windows Sidebar\Shared Gadgets\MyGadget" /grant Users:(IO)(OI)(CI)(F)

注意,这需要你对MyGadget目录具有充分权限,例如使用管理员帐号操作。