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.