404 - Dave's Blog

Search
My timeline on Mastodon

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 Sep 9, 4:38
@seattledaddy @thejohnjansen @k_seks its cause people don't think of hotdog as sandwich ☺
PermalinkComments

Tweet from David Risney

2016 Sep 8, 11:31
@thejohnjansen @k_seks or in the case of hotdog & sandwich, casual communication vs pedantic contrarianism
PermalinkComments

Tweet from David Risney

2016 Sep 8, 11:22
@thejohnjansen @k_seks right, diff goals like with Pluto. Casual communication vs technical communication
PermalinkComments

Tweet from David Risney

2016 May 13, 1:57
@KevinJHill @seattledaddy @k_seks https://twitter.com/SimoneGiertz/status/728595951246557186 
PermalinkComments

Retweet of SwiftOnSecurity

2016 Feb 16, 5:06
#MustRead Apple CEO Tim Cook's letter to customers on FBI's request for assistance hacking an iPhone 5c http://www.apple.com/customer-letter/ …
PermalinkComments

Retweet of AndyPavia

2016 Feb 11, 1:33
@k_seks @jarennert Using FaceDetect on a Raspberry Pi #WebOnPi #IoT #windows10 @MSEdgeDev pic.twitter.com/Qk2PyoedBP
PermalinkComments

Retweet of SwiftOnSecurity

2016 Feb 10, 11:21
The speed of light suuuuuucks
PermalinkComments

Retweet of FxSiteCompat

2016 Jan 27, 7:44
#Firefox 46 Developer Edition is out! Non-HTTPS pages w/ login form are now marked insecure https://www.fxsitecompat.com/versions/46/  pic.twitter.com/o2WZ6K2KxN
PermalinkComments

Retweet of vivisandroan

2015 Nov 13, 1:43
Parisians Use #PorteOuverte Hashtag for Those Seeking Safety From Attacks: The hashtag #PorteOuverte spread on... http://bit.ly/20Sc0TM 
PermalinkComments

Retweet of jboner

2015 Aug 18, 9:43
Will there be a Distributed HTTP? https://www.mnot.net/blog/2015/08/18/distributed_http …
PermalinkComments

thefrogman: Poorly Drawn Lines by Reza...

2013 Oct 15, 7:47


thefrogman:

Poorly Drawn Lines by Reza Farazmand
[website | tumblr | twitter | facebook]

PermalinkCommentshumor comic robot

Bug Spotting: Ctors with default parameters

2011 Dec 1, 4:59

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.

PermalinkCommentsc++ technical bug programming

2010_05_Dave_and_Sarah_Wedding_Jodee_and_Dave_II

2010 Jun 5, 3:54

PermalinkComments

2010_05_Dave_and_Sarah_Wedding_Sarah_Shows_off_the_Ring

2010 Jun 5, 3:54

PermalinkComments

2010_05_Dave_and_Sarah_Wedding_Dave_with_Mother_and_Mother-In-Law

2010 Jun 5, 3:54

PermalinkComments

2010_05_Dave_and_Sarah_Wedding_Dave_and_Jodee_Beach

2010 Jun 5, 3:54

PermalinkComments

2010_05_Dave_and_Sarah_Wedding_Dave_I

2010 Jun 5, 3:54

PermalinkComments

2010_05_Dave_and_Sarah_Wedding_Dave

2010 Jun 5, 3:54

PermalinkComments

2010_05_Dave_and_Sarah_Wedding_Michelle_and_Eileen_Post_Wedding_Walk

2010 Jun 5, 3:54

PermalinkComments
Older Entries Creative Commons License Some rights reserved.