file - Dave's Blog

Search

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.

PermalinkComments

Tweet from David Risney

2016 Dec 10, 10:07
Seems like @pushalotapp isn't on the Microsoft Store anymore? Will it come back?
PermalinkComments

Tweet from David Risney

2016 Dec 7, 10:04
@ericlaw that is a solid lock. Not getting through that lock!
PermalinkComments

Tweet from David Risney

2016 Dec 7, 5:30
@ericlaw @RReverser broke my screenshot muscle memory. Switched to snipping tool.
PermalinkComments

Tweet from Andy Baio

2016 Dec 6, 2:30
OH. MY. GOD. @SethBling MADE AN ATARI 2600 EMULATOR IN MINECRAFT. https://youtu.be/5nViIUfDMJg 
PermalinkComments

Tweet from David Risney

2016 Dec 5, 5:52
@davatron5000 I have a C:\users\dave\bin path I've added to my PATHS
PermalinkComments

Tweet from David Risney

2016 Dec 4, 2:26
Oh just realized Trevor, Simon, and Rebus are all the same person. Awesome. Assuming @StevenOgg isn't a robot
PermalinkComments

Tweet from David Risney

2016 Dec 4, 9:30
@AGoldmund Its my morning two minute hate. And then again around lunch time. And also just whenever.
PermalinkComments

Tweet from David Risney

2016 Nov 18, 4:11
@PA_Megacorp I read the title as Couchomancy and imagined a necromancer that summons couches. No one steal my new YA fantasy novel idea pls
PermalinkComments

Tweet from David Risney

2016 Nov 6, 1:17
@ericlaw Very fitting for the show but... those serifs. Aspects of 80s aesthetic I can do without include: wood paneling on cars, that font.
PermalinkComments

Let's Encrypt NearlyFreeSpeech.net Update

2016 Nov 5, 8:59

Since I had last posted about using Let's Encrypt with NearlyFreeSpeech, NFS has changed their process for setting TLS info. Instead of putting the various files in /home/protected/ssl and submitting an assistance request, now there is a command to submit the certificate info and a webpage for submitting the certificate info.

The webpage is https://members.nearlyfreespeech.net/{username}/sites/{sitename}/add_tls and has a textbox for you to paste in all the cert info in PEM form into the textbox. The domain key, the domain certificate, and the Let's Encrypt intermediate cert must be pasted into the textbox and submitted.

Alternatively, that same info may be provided as standard input to nfsn -i set-tls

To renew my certificate with the updated NFS process I followed the commands from Andrei Damian-Fekete's script which depends on acme_tiny.py:

python acme_tiny.py --account-key account.key --csr domain.csr --acme-dir /home/public/.well-known/acme-challenge/ > signed.crt
wget -O - https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem > intermediate.pem
cat domain.key signed.crt intermediate.pem > chained.pem
nfsn -i set-tls < chained.pem
Because my certificate had already expired I needed to comment out the section in acme_tiny.py that validates the challenge file. The filenames in the above map to the following:
  • signed.crt is the Let's Encrypt provided certificate
  • account.key is the user private key registered with LE
  • domain.csr is the cert request
  • domain.key is the key for the domain cert
PermalinkCommentscertificate lets-encrypt nearlyfreespeech.net

Tweet from David Risney

2016 Nov 4, 4:08
@David_Risney Example graph https://raw.githubusercontent.com/david-risney/WinMDGraph/master/examples/3/3.dot.png  of the Windows .Services.Maps namespace
PermalinkComments

Tweet from David Risney

2016 Nov 4, 1:48
@JenMsft Your tip weets should show as toasts for all win10 users
PermalinkComments

Tweet from David Risney

2016 Nov 3, 3:59
@FakeUnicode Spaces are technically not allowed in a URI so the only reasonable representation is percent encoded.
PermalinkComments

Tweet from David Risney

2016 Nov 3, 3:58
@FakeUnicode Reserved characters including brackets change meaning when decoded or encoded and so UA must not change those
PermalinkComments

Tweet from David Risney

2016 Nov 3, 3:57
@FakeUnicode At least some of that is from https://tools.ietf.org/html/rfc3986 . For unreserved characters (a-z0-9._-~) normal form is decoded.
PermalinkComments

Tweet from David Risney

2016 Nov 2, 1:16
@osterman @ericlaw 'CLR cooks' I assume means you get the .NET projection of the WinRT APIs? That's good enough for most of my purposes.
PermalinkComments

Tweet from David Risney

2016 Nov 2, 9:30
Parsing WinRT metadata (winmd files) is much easier than last time I tried. There's support in .NET reflection APIs https://deletethis.net/dave/2016-11/Parsing+WinMD+with+.NET+reflection+APIs 
PermalinkComments

Parsing WinMD with .NET reflection APIs

2016 Nov 2, 6:13

Parsing WinMD files, the containers of WinRT API metadata, is relatively simple using the appropriate .NET reflection APIs. However, figuring out which reflection APIs to use is not obvious. I've got a completed C sharp class parsing WinMD files that you can check out for reference.

Use System.Reflection.Assembly.ReflectionOnlyLoad to load the WinMD file. Don't use the normal load methods because the WinMD files contain only metadata. This will load up info about APIs defined in that WinMD, but any references to types outside of that WinMD including types found in the normal OS system WinMD files must be resolved by the app code via the System.Reflection.InteropServices.WindowsRuntimeMetadata.ReflectionOnlyNamespaceResolve event.

In this event handler you must resolve the unknown namespace reference by adding an assembly to the NamespaceResolveEventArgs's ResolvedAssemblies property. If you're only interested in OS system WinMD files you can use System.Reflection.InteropServices.WindowsRuntimeMetadata.ResolveNamespace to turn a namespace into the expected OS system WinMD path and turn that path into an assembly with ReflectionOnlyLoad.

PermalinkComments.net code programming winmd winrt

Tweet from David Risney

2016 Oct 23, 4:24
Didn't know retrospective realization of "that was a date" is common to super-smart-afraid-of-conflict narcissist’s club. Thx to @hodgman
PermalinkComments
Older Entries Creative Commons License Some rights reserved.