In Win8.1 JavaScript UWP apps we supported multiple windows using MSApp DOM APIs. In Win10 we use window.open and window and a new MSApp API getViewId and the previous MSApp APIs are gone:
Win10 | Win8.1 | |
---|---|---|
Create new window | window.open | MSApp.createNewView |
New window object | window | MSAppView |
viewId | MSApp.getViewId(window) | MSAppView.viewId |
We use window.open and window for creating new windows, but then to interact with WinRT APIs we add the MSApp.getViewId API. It takes a window object as a parameter and returns a viewId number that can be used with the various Windows.UI.ViewManagement.ApplicationViewSwitcher APIs.
Views in WinRT normally start hidden and the end developer uses something like TryShowAsStandaloneAsync
to display the view once it is fully prepared. In the web world, window.open shows a window immediately and the end user can watch as content is loaded and rendered. To have your new windows act
like views in WinRT and not display immediately we have added a window.open option. For example
let newWindow = window.open("https://example.com", null, "msHideView=yes");
The primary window that is initially opened by the OS acts differently than the secondary windows that it opens:
Primary | Secondary | |
---|---|---|
window.open | Allowed | Disallowed |
window.close | Close app | Close window |
Navigation restrictions | ACUR only | No restrictions |
The restriction on secondary windows such that they cannot open secondary windows could change in the future depending on feedback.
Lastly, there is a very difficult technical issue preventing us from properly supporting synchronous, same-origin, cross-window, script calls. That is, when you open a window that's same origin, script in one window is allowed to directly call functions in the other window and some of these calls will fail. postMessage calls work just fine and is the recommended way to do things if that's possible for you. Otherwise we continue to work on improving this.
A former State Department lawyer has his doubts, and a famous cartoonist predicts jury nullification.
In IE10 and other new browsers one may create MessageChannel objects that have two MessagePorts each connected (w3c spec calls it entangled) to one another such that postMessage on one port results in the message event firing on the other. You can pass an array of ports as the last parameter to postMessage and they show up in the ports property of the message event arg.
The postMessage here is like the worker postMessage and unlike the window and iframe postMessage in that it applies no origin checking:
Unfortunately the origin isn't an optional parameter at the end to make the two postMessages have the same signature.
On the event handler side, the event arg always has an origin property. But in the no origin case it is always the empty string.
There is also a source property on the message event arg which if set is an object that has a postMessage property allowing you to post back to your caller. It is set for the origin case, however, in the no origin case this property is null. This is somewhat reasonable because in the case of MessagePort and Workers there are only two endpoints so you always know the source of a message implicitly. Unlike the origin case in which any iframe or window can be calling postMessage on any other iframe or window and the caller is unknown. So not unreasonable but it would be nice if the source property was always set for consistency.
When a MessageChannel is created it has two MessagePorts, but until those ports are started they will queue up any messages they receive. Once started they will dispatch all queued messages. Ports don't have to be started to send messages.
A port may be started in two ways, either by explicitly calling the start method on the port, or by setting the onmessage callback property on the port. However, adding an event listener via addEventListener("message", does not start the port. It works this way in IE and Chrome and the spec states this as well.
The justification is that since you can have only one callback via onmessage that once set you must implicitly be ready to receive messages and its fine to start the port. As opposed to the addEventListener in which case the user agent cannot start implicitly because it doesn't know how many event listeners will be added. I found Hixie stating this justification in geoloc meeting notes.
The following code compiled just fine but did not at all act in the manner I expected:
BOOL CheckForThing(__in CObj *pObj, __in IFigMgr* pFigMgr, __in_opt LPCWSTR url)
{
BOOL fCheck = FALSE;
if (SubCheck(pObj))
{
...
I’m
calling SubCheck which looks like:
bool SubCheck(const CObj& obj);
Did you spot the bug? As you can see I should be passing in *pObj not pObj since the method takes a const CObj& not a CObj*. But then why does it compile?
It works because CObj has a constructor with all but one param with default values and CObj is derived from IUnknown:
CObj(__in_opt IUnknown * pUnkOuter, __in_opt LPCWSTR pszUrl = NULL);
Accordingly C++ uses this constructor as an implicit conversion operator. So instead of passing in my
CObj, I end up creating a new CObj on the stack passing in the CObj I wanted as the outer object which has a number of issues.
The lesson is unless you really want this behavior, don't make constructors with all but 1 or 0 default parameters. If you need to do that consider using the 'explicit' keyword on the constructor.
More info about forcing single argument constructors to be explicit is available on stack overflow.
I always have trouble remembering where the opt goes in SAL in the __deref_out case. The mnemonic is pretty simple: the _opt at the start of the SAL is for the pointer value at the start of the function. And the _opt at the end of the SAL is for the dereferenced pointer value at the end of the function.
SAL | foo == nullptr allowed at function start? | *foo == nullptr allowed at function end? |
---|---|---|
__deref_out void **foo | No | No |
__deref_opt_out void **foo | Yes | No |
__deref_out_opt void **foo | No | Yes |
__deref_opt_out_opt void **foo | Yes | Yes |
Working on GeolocMock it took me a bit to realize why my HTML could use the W3C Geolocation API in IE9 but not in my WebBrowser control in my .NET application. Eventually I realized that I was getting the wrong IE doc mode. Reading this old More IE8 Extensibility Improvements IE blog post from the IE blog I found the issue is that for app compat the WebOC picks older doc modes but an app hosting the WebOC can set a regkey to get different doc modes. The IE9 mode isn't listed in that article but I took a guess based on the values there and the decimal value 9999 gets my app IE9 mode. The following is the code I run in my application to set its regkey so that my app can get the IE9 doc mode and use the geolocation API.
static private void UseIE9DocMode()
{
RegistryKey key = null;
try
{
key = Registry.CurrentUser.OpenSubKey("Software\\Microsoft\\Internet Explorer\\Main\\FeatureControl\\FEATURE_BROWSER_EMULATION", true);
}
catch (Exception)
{
key = Registry.CurrentUser.CreateSubKey("Software\\Microsoft\\Internet Explorer\\Main\\FeatureControl\\FEATURE_BROWSER_EMULATION");
}
key.SetValue(System.Diagnostics.Process.GetCurrentProcess().MainModule.ModuleName, 9999, RegistryValueKind.DWord);
key.Close();
}
var createNewXMLObj = function() {
var result = new ActiveXObject("MSXML2.FreeThreadedDOMDocument");
result.validateOnParse = false;
result.async = false;
return result;
}
var args = WScript.arguments;
var ofs = WScript.CreateObject("Scripting.FileSystemObject");
var xslParams = [];
var xmlStyle = null;
var xmlInput = null;
var inputFile = null;
var outputFile = null;
var error = false;
for (var idx = 0; idx < args.length && !error; ++idx)
if (args.item(idx) == "-o") {
if (idx + 1 < args.length) {
outputFile = ofs.GetAbsolutePathName(args.item(idx + 1));
++idx;
}
else
error = true;
}
else if (args.item(idx) == "--param" || args.item(idx) == "-param") {
if (idx + 2 < args.length) {
xslParams[args.item(idx + 1)] = args.item(idx + 2);
idx += 2;
}
else
error = true;
}
else if (xmlStyle == null) {
xmlStyle = createNewXMLObj();
xmlStyle.load(ofs.GetAbsolutePathName(args.item(idx)));
}
else if (xmlInput == null) {
inputFile = ofs.GetAbsolutePathName(args.item(idx));
xmlInput = createNewXMLObj();
xmlInput.load(inputFile);
}
if (xmlStyle == null || xmlInput == null || error) {
WScript.Echo('Usage:\n\t"xsltproc" xsl-stylesheet input-file\n\t\t["-o" output-file] *["--param" name value]');
}
else {
var xslt = new ActiveXObject("MSXML2.XSLTemplate.3.0");
xslt.stylesheet = xmlStyle;
var xslProc = xslt.createProcessor();
xslProc.input = xmlInput;
for (var keyVar in xslParams)
xslProc.addParameter(keyVar, xslParams[keyVar]);
xslProc.transform();
if (outputFile == null)
WScript.Echo(xslProc.output);
else {
var xmlOutput = createNewXMLObj();
xmlOutput.loadXML(xslProc.output);
xmlOutput.save(outputFile);
}
}