JavaScript Microsoft Store app StartPage

2017 Jun 22, 8:58

JavaScript Microsoft Store apps have some details related to activation that are specific to JavaScript Store apps and that are poorly documented which I’ll describe here.

StartPage syntax

The StartPage attributes in the AppxManifest.xml (Package/Applications/Application/@StartPage, Package/Applications/Extensions/Extension/@StartPage) define the HTML page entry point for that kind of activation. That is, Application/@StartPage defines the entry point for tile activation, Extension[@Category="windows.protocol"]/@StartPage defines the entry point for URI handling activation, etc. There are two kinds of supported values in StartPage attributes: relative Windows file paths and absolute URIs. If the attribute doesn’t parse as an absolute URI then it is instead interpreted as relative Windows file path.

This implies a few things that I’ll declare explicitly here. Windows file paths, unlike URIs, don’t have a query or fragment, so if you are using a relative Windows file path for your StartPage attribute you cannot include anything like ‘?param=value’ at the end. Absolute URIs use percent-encoding for reserved characters like ‘%’ and ‘#’. If you have a ‘#’ in your HTML filename then you need to percent-encode that ‘#’ for a URI and not for a relative Windows file path.

If you specify a relative Windows file path, it is turned into an ms-appx URI by changing all backslashes to forward slashes, percent-encoding reserved characters, and combining the result with a base URI of ms-appx:///. Accordingly the relative Windows file paths are relative to the root of your package. If you are using a relative Windows file path as your StartPage and need to switch to using a URI so you can include a query or fragment, you can follow the same steps above.

StartPage validity

The validity of the StartPage is not determined before activation. If the StartPage is a relative Windows file path for a file that doesn’t exist, or an absolute URI that is not in the Application Content URI Rules, or something that doesn’t parse as a Windows file path or URI, or otherwise an absolute URI that fails to resolve (404, bad hostname, etc etc) then the JavaScript app will navigate to the app’s navigation error page (perhaps more on that in a future blog post). Just to call it out explicitly because I have personally accidentally done this: StartPage URIs are not automatically included in the Application Content URI Rules and if you forget to include your StartPage in your ACUR you will always fail to navigate to that StartPage.

StartPage navigation

When your app is activated for a particular activation kind, the StartPage value from the entry in your app’s manifest that corresponds to that activation kind is used as the navigation target. If the app is not already running, the app is activated, navigated to that StartPage value and then the Windows.UI.WebUI.WebUIApplication activated event is fired (more details on the order of various events in a moment). If, however, your app is already running and an activation occurs, we navigate or don’t navigate to the corresponding StartPage depending on the current page of the app. Take the app’s current top level document’s URI and if after removing the fragment it already matches the StartPage value then we won’t navigate and will jump straight to firing the WebUIApplication activated event.

Since navigating the top-level document means destroying the current JavaScript engine instance and losing all your state, this behavior might be a problem for you. If so, you can use the MSApp.pageHandlesAllApplicationActivations(true) API to always skip navigating to the StartPage and instead always jump straight to firing the WebUIApplication activated event. This does require of course that all of your pages all handle all activation kinds about which any part of your app cares.

Tweet from David_Risney

2016 Jan 17, 5:39

Previously unaware how much of a monster truck show is spent towing and repairing monster trucks. pic.twitter.com/APGXMglRXQ

Retweet of Esquiring

2015 Nov 23, 10:32

#TIL someone virtualized a bunch of networked Tamagotchis and has an AI caring for them. http://tamahive.spritesserver.nl/ pic.twitter.com/3GUJ30RNGj

Tweet from David_Risney

2015 Oct 13, 9:43

Neat hack: use victim's headphone wire as antenna to send audio commands to their phone's Siri http://www.wired.com/2015/10/this-radio-trick-silently-hacks-siri-from-16-feet-away/ …

Retweet of KevinJHill

2015 Jul 22, 8:04

The Microsoft Edge @MSEdgeDev team is hiring a Senior Software Engineer! http://bit.ly/1CRaQz8 . Help us make the web better #cpp #jobs

Retweet of KevinJHill

2015 Jul 22, 7:12

The Microsoft Edge team @MSEdgeDev is hiring C++ Devs! http://bit.ly/1MJxEAX , help us make the web better!

Netflix API : Retiring the Netflix Public API

2014 Jun 15, 3:02

First they came for our RSS feeds and I said nothing…

URI Design and Ownership - IETF Draft

2014 May 21, 2:06

URI Design & Ownership - On the issues with and alternatives to requiring well known filenames and extensions in URIs. You must love the draft’s URI.

technical uri

URI functions in Windows Store Applications

2013 Jul 25, 1:00

Summary

The Modern SDK contains some URI related functionality as do libraries available in particular projection languages. Unfortunately, collectively these APIs do not cover all scenarios in all languages. Specifically, JavaScript and C++ have no URI building APIs, and C++ additionally has no percent-encoding/decoding APIs.

	WinRT (JS and C++)	JS Only	C++ Only	.NET Only
Parse	Windows.Foundation.Uri		WsDecodeUrl*	System.Uri
Build			WsEncodeUrl*	System.UriBuilder
Normalize	Windows.Foundation.Uri			System.Uri
Equality	Windows.Foundation.Uri. Equals			System.Uri.Compare
Relative resolution	Windows.Foundation.Uri. CombineUri			System.Uri
Encode data for including in URI property	Windows.Foundation.Uri. EscapeComponent	encodeURIComponent	WsEncodeUrl*	System.Uri. EscapeDataString
Decode data extracted from URI property	Windows.Foundation.Uri. UnescapeComponent	decodeURIComponent	WsDecodeUrl*	System.Uri. UnescapeDataString
Build Query
Parse Query	Windows.Foundation. Uri.QueryParsed / Windows.Foundation. WwwFormUrlDecoder*

The Windows.Foudnation.Uri type is not projected into .NET modern applications. Instead those applications use System.Uri and the platform ensures that it is correctly converted back and forth between Windows.Foundation.Uri as appropriate. Accordingly the column marked WinRT above is applicable to JS and C++ modern applications but not .NET modern applications. The only entries above applicable to .NET are the .NET Only column and the WwwFormUrlDecoder in the bottom left which is available to .NET.

Scenarios

Parse

This functionality is provided by the WinRT API Windows.Foundation.Uri in C++ and JS, and by System.Uri in .NET.

Parsing a URI pulls it apart into its basic components without decoding or otherwise modifying the contents.

var uri = new Windows.Foundation.Uri("http://example.com/path%20segment1/path%20segment2?key1=value1&key2=value2");

console.log(uri.path);// /path%20segment1/path%20segment2

WsDecodeUrl (C++)

WsDecodeUrl is not suitable for general purpose URI parsing. Use Windows.Foundation.Uri instead.

Build (C#)

URI building is only available in C# via System.UriBuilder.

URI building is the inverse of URI parsing: URI building allows the developer to specify the value of basic components of a URI and the API assembles them into a URI.

To work around the lack of a URI building API developers will likely concatenate strings to form their URIs. This can lead to injection bugs if they don’t validate or encode their input properly, but if based on trusted or known input is unlikely to have issues.

Uri originalUri = new Uri("http://example.com/path1/?query");

UriBuilder uriBuilder = new UriBuilder(originalUri);

uriBuilder.Path = "/path2/";

Uri newUri = uriBuilder.Uri; // http://example.com/path2/?query

WsEncodeUrl (C++)

WsEncodeUrl, in addition to building a URI from components also does some encoding. It encodes non-US-ASCII characters as UTF8, the percent, and a subset of gen-delims based on the URI property: all :/?#[]@ are percent-encoded except :/@ in the path and :/?@ in query and fragment.

Accordingly, WsEncodeUrl is not suitable for general purpose URI building. It is acceptable to use in the following cases:

- You’re building a URI out of non-encoded URI properties and don’t care about the difference between encoded and decoded characters. For instance you’re the only one consuming the URI and you uniformly decode URI properties when consuming – for instance using WsDecodeUrl to consume the URI.

- You’re building a URI with URI properties that don’t contain any of the characters that WsEncodeUrl encodes.

Normalize

This functionality is provided by the WinRT API Windows.Foundation.Uri in C++ and JS and by System.Uri in .NET. Normalization is applied during construction of the Uri object.

URI normalization is the application of URI normalization rules (including DNS normalization, IDN normalization, percent-encoding normalization, etc.) to the input URI.

var normalizedUri = new Windows.Foundation.Uri("HTTP://EXAMPLE.COM/p%61th foo/");

console.log(normalizedUri.absoluteUri); // http://example.com/path%20foo/

This is modulo Win8 812823 in which the Windows.Foundation.Uri.AbsoluteUri property returns a normalized IRI not a normalized URI. This bug does not affect System.Uri.AbsoluteUri which returns a normalized URI.

Equality

This functionality is provided by the WinRT API Windows.Foundation.Uri in C++ and JS and by System.Uri in .NET.

URI equality determines if two URIs are equal or not necessarily equal.

var uri1 = new Windows.Foundation.Uri("HTTP://EXAMPLE.COM/p%61th foo/"),

uri2 = new Windows.Foundation.Uri("http://example.com/path%20foo/");

console.log(uri1.equals(uri2)); // true

Relative resolution

This functionality is provided by the WinRT API Windows.Foundation.Uri in C++ and JS and by System.Uri in .NET

Relative resolution is a function that given an absolute URI A and a relative URI B, produces a new absolute URI C. C is the combination of A and B in which the basic components specified in B override or combine with those in A under rules specified in RFC 3986.

var baseUri = new Windows.Foundation.Uri("http://example.com/index.html"),

relativeUri = "/path?query#fragment",

absoluteUri = baseUri.combineUri(relativeUri);

console.log(baseUri.absoluteUri); // http://example.com/index.html

console.log(absoluteUri.absoluteUri); // http://example.com/path?query#fragment

Encode data for including in URI property

This functionality is available in JavaScript via encodeURIComponent and in C# via System.Uri.EscapeDataString. Although the two methods mentioned above will suffice for this purpose, they do not perform exactly the same operation.

Additionally we now have Windows.Foundation.Uri.EscapeComponent in WinRT, which is available in JavaScript and C++ (not C# since it doesn’t have access to Windows.Foundation.Uri). This is also slightly different from the previously mentioned mechanisms but works best for this purpose.

Encoding data for inclusion in a URI property is necessary when constructing a URI from data. In all the above cases the developer is dealing with a URI or substrings of a URI and so the strings are all encoded as appropriate. For instance, in the parsing example the path contains “path%20segment1” and not “path segment1”. To construct a URI one must first construct the basic components of the URI which involves encoding the data. For example, if one wanted to include “path segment / example” in the path of a URI, one must percent-encode the ‘ ‘ since it is not allowed in a URI, as well as the ‘/’ since although it is allowed, it is a delimiter and won’t be interpreted as data unless encoded.

If a developer does not have this API provided they can write it themselves. Percent-encoding methods appear simple to write, but the difficult part is getting the set of characters to encode correct, as well as handling non-US-ASCII characters.

var uri = new Windows.Foundation.Uri("http://example.com" +

"/" + Windows.Foundation.Uri.escapeComponent("path segment / example") +

"?key=" + Windows.Foundation.Uri.escapeComponent("=&?#"));

console.log(uri.absoluteUri); // http://example.com/path%20segment%20%2F%20example?key=%3D%26%3F%23

WsEncodeUrl (C++)

In addition to building a URI from components, WsEncodeUrl also percent-encodes some characters. However the API is not recommend for this scenario given the particular set of characters that are encoded and the convoluted nature in which a developer would have to use this API in order to use it for this purpose.

There are no general purpose scenarios for which the characters WsEncodeUrl encodes make sense: encode the %, encode a subset of gen-delims but not also encode the sub-delims. For instance this could not replace encodeURIComponent in a C++ version of the following code snippet since if ‘value’ contained ‘&’ or ‘=’ (both sub-delims) they wouldn’t be encoded and would be confused for delimiters in the name value pairs in the query:

"http://example.com/?key=" + Windows.Foundation.Uri.escapeComponent(value)

Since WsEncodeUrl produces a string URI, to obtain the property they want to encode they’d need to parse the resulting URI. WsDecodeUrl won’t work because it decodes the property but Windows.Foundation.Uri doesn’t decode. Accordingly the developer could run their string through WsEncodeUrl then Windows.Foundation.Uri to extract the property.

Decode data extracted from URI property

This functionality is available in JavaScript via decodeURIComponent and in C# via System.Uri.UnescapeDataString. Although the two methods mentioned above will suffice for this purpose, they do not perform exactly the same operation.

Additionally we now also have Windows.Foundation.Uri.UnescapeComponent in WinRT, which is available in JavaScript and C++ (not C# since it doesn’t have access to Windows.Foundation.Uri). This is also slightly different from the previously mentioned mechanisms but works best for this purpose.

Decoding is necessary when extracting data from a parsed URI property. For example, if a URI query contains a series of name and value pairs delimited by ‘=’ between names and values, and by ‘&’ between pairs, one must first parse the query into name and value entries and then decode the values. It is necessary to make this an extra step separate from parsing the URI property so that sub-delimiters (in this case ‘&’ and ‘=’) that are encoded will be interpreted as data, and those that are decoded will be interpreted as delimiters.

If a developer does not have this API provided they can write it themselves. Percent-decoding methods appear simple to write, but have some tricky parts including correctly handling non-US-ASCII, and remembering not to decode .

In the following example, note that if unescapeComponent were called first, the encoded ‘&’ and ‘=’ would be decoded and interfere with the parsing of the name value pairs in the query.

var uri = new Windows.Foundation.Uri("http://example.com/?foo=bar&array=%5B%27%E3%84%93%27%2C%27%26%27%2C%27%3D%27%2C%27%23%27%5D");

uri.query.substr(1).split("&").forEach(

function (keyValueString) {

var keyValue = keyValueString.split("=");

console.log(Windows.Foundation.Uri.unescapeComponent(keyValue[0]) + ": " + Windows.Foundation.Uri.unescapeComponent(keyValue[1]));

// foo: bar

// array: ['ㄓ','&','=','#']

});

WsDecodeUrl (C++)

Since WsDecodeUrl decodes all percent-encoded octets it could be used for general purpose percent-decoding but it takes a URI so would require the dev to construct a stub URI around the string they want to decode. For example they could prefix “http:///#” to their string, run it through WsDecodeUrl and then extract the fragment property. It is convoluted but will work correctly.

Parse Query

The query of a URI is often encoded as application/x-www-form-urlencoded which is percent-encoded name value pairs delimited by ‘&’ between pairs and ‘=’ between corresponding names and values.

In WinRT we have a class to parse this form of encoding using Windows.Foundation.WwwFormUrlDecoder. The queryParsed property on the Windows.Foundation.Uri class is of this type and created with the query of its Uri:

var uri = Windows.Foundation.Uri("http://example.com/?foo=bar&array=%5B%27%E3%84%93%27%2C%27%26%27%2C%27%3D%27%2C%27%23%27%5D");

uri.queryParsed.forEach(

function (pair) {

console.log("name: " + pair.name + ", value: " + pair.value);

// name: foo, value: bar

// name: array, value: ['ㄓ','&','=','#']

});

console.log(uri.queryParsed.getFirstValueByName("array")); // ['ㄓ','&','=','#']

The QueryParsed property is only on Windows.Foundation.Uri and not System.Uri and accordingly is not available in .NET. However the Windows.Foundation.WwwFormUrlDecoder class is available in C# and can be used manually:

Uri uri = new Uri("http://example.com/?foo=bar&array=%5B%27%E3%84%93%27%2C%27%26%27%2C%27%3D%27%2C%27%23%27%5D");

WwwFormUrlDecoder decoder = new WwwFormUrlDecoder(uri.Query);

foreach (IWwwFormUrlDecoderEntry entry in decoder)

{

System.Diagnostics.Debug.WriteLine("name: " + entry.Name + ", value: " + entry.Value);

// name: foo, value: bar

// name: array, value: ['ㄓ','&','=','#']

}

Build Query

To build a query of name value pairs encoded as application/x-www-form-urlencoded there is no WinRT API to do this directly. Instead a developer must do this manually making use of the code described in “Encode data for including in URI property”.

In terms of public releases, this property is only in the RC and later builds.

For example in JavaScript a developer may write:

var uri = new Windows.Foundation.Uri("http://example.com/"),

query = "?" + Windows.Foundation.Uri.escapeComponent("array") + "=" + Windows.Foundation.Uri.escapeComponent("['ㄓ','&','=','#']");

console.log(uri.combine(new Windows.Foundation.Uri(query)).absoluteUri); // http://example.com/?array=%5B'%E3%84%93'%2C'%26'%2C'%3D'%2C'%23'%5D

c# c++ javascript technical uri windows windows-runtime windows-store

Subtleties of postMessage

2013 Jul 15, 1:00

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.

Origin

The postMessage here is like the worker postMessage and unlike the window and iframe postMessage in that it applies no origin checking:

No origin postMessage in workers and MessagePorts: postMessage(messageData, ports)
Origin postMessage in windows and iframes: postMessage(messageData, targetOrigin, ports)

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.

Source

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.

MessageChannel start

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.

Links

W3C Spec

Opera introduction

DOM html javascript postMessage technical web-worker worker

Funny People: Steve Heinrich, You Don’t Know Jack head writer | Interview | The Gameological Society

2012 Jul 1, 3:38

A veteran of the satirical trivia game series since its first heyday in the 1990s, Heinrich talks about Jack’s writing process, its long hiatus, and that short-lived live-action TV version.

game interview video-game you-dont-know-jack ydkj

Spirit of Indiana (Jones) – syncing HTML5 Video with Maps ✩ Mozilla Hacks – the Web developer blog

2010 Dec 16, 1:12Nice! Indiana Jones style map fade in over video done in HTML5 with video tag, and Google maps API.

html5 video map technical demo google animation svg

Peer-to-peer tech now powers Wikipedia's videos

2010 Sep 27, 3:15This is awesome and similar to something I got a cube for. Wikipedia runs its videos through a service that sets up torrents for arbitrary URLs. So awesome! Now if only this were built into the user agent rather than requiring hardcoding the sites to use it...

technical p2p wikipedia network networking torrent web

INTERCAL -- the Language From Hell

2010 May 10, 5:21An old article by Charles Stross on INTERCAL the satirical programming language. It contains great features such as 'come from' the inverse of 'goto'.

c programming humor technical language software charles-stross intercal goto

Childrens' Hospital: Watch Full Episodes on TheWB.com. Starring Hot Tub Time Machine's Rob Corddry

2010 Apr 5, 10:41A satirical hospital drama TV show starring tons of humorous people like Rob Corddry, David Wain, Jason Sudeikis and many many more people who you will recognize but not necessarily know their name.

humor tv hospital satire rob-corddry

Two Gentlemen of Lebowski

2010 Jan 8, 1:53Two Gentlemen of Lebowski, by Adam Bertocci: "Thou err’st; no man calls me Lebowski. Yet thou art man; neither spirit damned nor wandering shadow, thou art solid flesh, man of woman born. Hear rightly, man!—for thou hast got the wrong man. I am the Knave, man; Knave in nature as in name."

humor via:ethan_t_hein shakespeare the-big-lebowski play parody english

curlies - Project Hosting on Google Code

2009 Dec 23, 9:58Results of a set of black box tests on various characters in various parts of URLs in various popular browsers.

via:mnot url uri iri idn dns browser web technical

There is no WebKit on Mobile

2009 Oct 7, 8:10Quirksmode does a chart comparing the differences in various versions of WebKit: "There’s iPhone WebKit, Android WebKit, S60 WebKit (at least two versions each), Bolt, Iris, Ozone, and Palm Pre, and I don’t doubt that I’ve overlooked a few minor WebKits along the way. All 10 mobile WebKits I’ve identified so far are subtly or wildly different."

compatibility web development browser webkit apple google android iphone safari technical via:mattb

Internet Archive: Free Download: The Spirituals to Swing Concerts of 1938 - 1939 (April 11, 1971)

2009 Sep 25, 12:14"Phil Elwood presents the complete recordings of two concerts organized by John Hammond and given on the Christmas Eves of 1938 and 1939 at Carnegie Hall; featuring the best Swing, Blues, and Gospel musicians of the day. Performers include Charlie Christian, Lester Young, Count Basie, Benny Goodman, Bill Broozy, and many others"

music cc swing concert

Internationalized Resource Identifiers (IRIs)

2009 Jul 29, 5:48The new draft IRI spec to replace RFC 3987. "To accomodate widespread current practice, additional derivative protocol elements are defined, and current practice for resolving IRI-based hypertext references in HTML are outlined."

iri uri rfc html reference technical