Geoff Chappell - Software Analyst
SKETCH OF HOW RESEARCH MIGHT CONTINUE AND RESULTS BE PRESENTED
From MSHTML.IDL in the Windows SDK:
[ propget, id (DISPID_IHTMLDIALOG_DIALOGARGUMENTS) ] HRESULT dialogArguments ([retval, out] VARIANT *p);
The DISPID, defined symbolically in MSHTMDID.H, evaluates as 25000.
The dialogArguments property requires an IHTMLDialog interface. The only MSHTML class that exposes this interface is HTMLDialog. The property is to be read by script in a document that is loaded in an HTML dialog box or property sheet. The HTMLDialog instance is effectively the document host. Script in the document accesses the host through the external object, itself found as a property of the window object. To such script, dialogArguments looks like a property of either the external or the window object.
The p argument for the get_dialogArguments method is an address at which the method is to store the dialog arguments. In script, whatever the method stores at this address, if returning success, becomes the value of the dialogArguments property.
The method returns zero for success, else an error code.
The ordinary behaviour is to copy as the value of dialogArguments whatever was provided as the dialog arguments when creating the dialog, e.g., through the pvarArgIn argument to the ShowHTMLDialogEx function or to a window object’s showModalDialog method.
The method fails if p is NULL. Though the p argument has no in attribute in Microsoft’s declaration, the method’s present coding does assume that p addresses a VARIANT as input which must be cleared before the method can proceed. Failure when clearing this input becomes failure of the method. Note that clearing uninitialised input can induce MSHTML to call an address at which there is no meaningful code, e.g., if the word at p happens to contain 0x09 (VT_DISPATCH) or 0x0D (VT_UNKNOWN), because clearing the VARIANT then means releasing an interface.
Of course, neither of the failures described in the preceding paragraph are likely to be possible when the property is accessed from script, since the actual caller will be Microsoft’s own code. Inspection confirms that MSHTML’s InvokeEx for the COmWindowProxy class always calls get_dialogArguments with p addressing a VARIANT filled with null bytes.
A quirk that can apply to script is that even if dialog arguments were provided for the dialog box, they are not necessarily available through the dialogArguments property. If the security ID of the document in the dialog box is not the same as that of the dialog box’s creator, then dialogArguments evaluates as null. This is an arguably sensible protection against data being passed where it might not have been wanted to go, but it doesn’t seem to get much documentation.