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.
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.
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.
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.
The thing where you remember old versions of the spec and, despite being the "expert"
in the room, can't recall what was eventually decided.
I watched ep1 of Murder in the First last night and Taye Diggs followed me this
morning. Coincidence? Or maybe he's into my CSP extension.
How to decide to trust a password mgr? Have to write my own to be sure of author's
intentions. But then also sure mgr will have dumb flaws.
We finally did what we should've done forever ago: filled a party bag with restaurant
names so we never have to decide again.
Jacob Rossi
@jacobrossi :As the title suggests, spoilers for The Interview follow.
Towards the end of the movie, after Dave Skylark is shot, he miraculously has a bullet proof vest, blows up Kim Jong-un, finds a random tunnel and is picked up by Seal Team Six. These are the same details of the unbelievable scenario that Dave Skylark describes to Agent Lacey at the beginning of the movie.
This isn't a coincidence. Everything after Dave is shot is his fantasizing about how things should have gone as he dies in the interview chair. Unsurprisingly his fantasy closely matches his original ridiculous thoughts about how he would assassinate and escape.
This is similar to movies like Brazil in which the later fourth of the movie is the main character’s romantic fantasy as he is tortured and killed in real life. Or Total Recall where the end of the movie matches the description of the memories that the main character will have implanted at the beginning.
Its safe to assume that after Dave is killed, Aaron and Sook are captured and also killed.
Quadrilateral Cowboy gameplay video
“Quadrilateral Cowboy is a game we’ve been watching with great interest ever since Thirty Flights Of Loving creator Brendon Chung first debuted it last year. It’s about hacking, but not via irritating minigames or jargon-your-problems-away Hollywood magic. Instead, you learn basic (albeit fictional) code and take down everything from laser grids to gun emplacements with a twitch of your fingers and a wriggle of your brain. It’s already an extremely clever game, and it’s quite empowering despite the fact that you play as someone who probably couldn’t even heft an assault rifle - let alone fire one. Basically, it’s a wonderfully novel idea - more Neuromancer than Deus Ex - but words only do it so much justice. Thus, I’ve decided to play it for your enrichment, in hopes that you will understand why Quadrilateral should be driving your radar haywire.”
Level3 counters Verizon’s recent post about Netflix traffic.
"In fact, Level 3 has asked Verizon for a long time to add interconnection capacity and to deliver the traffic its customers are requesting from our customers, but Verizon refuses."
Some time back while I was working on getting the Javascript Windows Store app platform running on Windows Phone (now available on the last Windows Phone release!) I had an interesting bug that in retrospect is amusing.
I had just finished a work item to get accessibility working for JS WinPhone apps when I got a new bug: With some set of JS apps, accessibility appeared to be totally broken. At that time in development the only mechanism we had to test accessibility was a test tool that runs on the PC, connects to the phone, and dumps out the accessibility tree of whatever app is running on the phone. In this bug, the tool would spin for a while and then timeout with an error and no accessibility information.
My first thought was this was an issue in my new accessibility code. However, debugging with breakpoints on my code I could see none of my code was run nor the code that should call it. The code that called that code was a more generic messaging system that hit my breakpoints constantly.
Rather than trying to work backward from the failure point, I decided to try and narrow down the repro and work forwards from there. One thing all the apps with the bug had in common was their usage of WinJS, but not all WinJS apps demonstrated the issue. Using a binary search approach on one such app I removed unrelated app code until all that was left was the app's usage of the WinJS AppBar and the bug still occurred. I replaced the WinJS AppBar usage with direct usage of the underlying AppBar WinRT APIs and continued.
Only some calls to the AppBar WinRT object produced the issue:
EFF litigates the US governnent into still more transparency into how it decides to use
0days, by 
Guardian sub makes small typo and accidentally loses all his
income. 
var appBar = Windows.UI.WebUI.Core.WebUICommandBar.getForCurrentView();
// appBar.opacity = 1;
// appBar.closeDisplayMode = Windows.UI.WebUI.Core.WebUICommandBarClosedDisplayMode.default;
appBar.backgroundColor = Windows.UI.Colors.white; // Bug!
I eventually realized that predefined WinRT color values like Windows.UI.Colors.aqua would cause the issue while JS literal based colors didn't cause the issue (Windows.UI.Color is a WinRT struct which projects in JS as a JS literal object with the struct members as JS
object properties so its easy to write something like {r: 0, g: 0, b: 0, a: 0} to make a color) and I had been mixing both in my tests without realizing there would be a difference.
I debugged into the backgroundColor property setter that consumed the WinRT color struct to see what was different between Windows.UI.Colors.black and {a: 1, r: 0, g: 0, b: 0} and
found the two structs to be byte wise exactly the same.
On a hunch I tried my test app with only a reference to the color and otherwise no interaction with the AppBar and not doing anything with the actual reference to the color:
Windows.UI.Colors.black;. This too caused the issue. I knew that the implementation for these WinRT const values live in a DLL and guessed that something in the code to create these
predefined colors was causing the issue. I debugged in and no luck. Now I also have experienced crusty code that would do exciting things in its DllMain, the function that's called when a DLL is loaded into the process so I tried modifying my
C++ code to simply LoadLibrary the DLL containing the WinRT color definition, windows.ui.xaml.dll and found the bug still occurred! A short lived moment of relief as the world seemed to make
sense again.
Debugging into DllMain nothing interesting happened. There were interesting calls in there to be sure, but all of them behind conditions that were false. I was again stumped. On another hunch I tried renaming the DLL and only LoadLibrary'ing it and the bug went away. I took a different DLL renamed it windows.ui.xaml.dll and tried LoadLibrary'ing that and the bug came back. Just the name of the DLL was causing the issue.
I searched for the DLL name in our source code index and found hits in the accessibility tool. Grinning I opened the source to find that the accessibility tool's phone side service was trying to determine if a process belonged to a XAML app or not because XAML apps had a different accessibility contract. It did this by checking to see if windows.ui.xaml.dll was loaded in the target process.
At this point I got to fix my main issue and open several new bugs for the variety of problems I had just run into. This is a how to on writing software that is difficult to debug.
When writing a JavaScript library that uses postMessage and the message event, I must be considerate of other JS code that will be
running along side my library. I shouldn't assume I'm the only sender and receiver on a caller provided MessagePort object. This means obviously I should use addEventListener("message" rather than
the onmessage property (see related What if two programs did this?). But considering the actual messages traveling
over the message channel I have the issue of accidentally processing another libraries messages and having another library accidentally process my own message. I have a few options for playing nice
in this regard:To decide what Gob’s bad impression of a chicken might be, Arnett consulted on set in 2003 with series executive producers Mitch Hurwitz and James Vallely. They all tried out different versions for each other. “Jimmy started doing a little bit, then Mitch got up and did some, and then I began trying things,” remembers Arnett. “Picture three grown men hopping around, working out what it would be … They were pitching this really taunting dance, but I wanted to give it this very sharp, almost roosterlike, chest-sticking-out mannerism, like a real macho bravado dance.” And how did clapping get introduced to the move? “Because I wanted it to be only sort of threatening.”
This is essentially an AV exploit against Super Mario World that results in running the end game code. Watch the video. “…there’s a glitch that’s been known for a while, where Yoshi can end up in the “I have an item in my mouth” state, but not actually have an item in his mouth. When he spits out this nothingness, the game crashes. …That address did not contain code, and so the system crashed. But wait a second. What if, by some sheer coincidence, that address did contain code? The specific address dropped him in somewhere amongst various data for the game’s internal random number generator, and the random number generator can be manipulated in a TAS. Could the game be coerced into running arbitrary code?…”
Some rights reserved