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:
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!
Just
setting the background color appeared to cause the issue and I didn't even have to display the AppBar. Through additional trial and error I was blown away to discover that some colors I would set
caused the issue and other colors did not. Black wouldn't cause the issue but transparent black would. So would aqua but not white.
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.
Monty Hall Problem - Numberphile
The Monty Hall problem made intuitive: instead of 3 doors, you have 100. You pick one door and then Monty opens 98 more doors and lets you switch to the remaining door. Well yeah now I’m going to switch.
"The Flexbox Layout (Flexible Box) module (currently a W3C Candidate Recommendation) aims at providing a more efficient way to lay out, align and…"
Great diagrams showing the use of the various flex css properties. I can never keep them straight so this is perfect for me.
YouTube - June System Update Walkthrough for Xbox One
OneGuide on SmartGlass is coming in the June Xbox One update! The feature I’ve been missing since day one. I don’t think I’m an average Xbox One user.
@youtube - How DNA Changed the World of Forensics | Retro Report | The New York Times
YouTube - Dead Man’s Bones (Dance)
Nathan Barnatt has some great videos
Does it betray my innocence that I’m shocked by the amount of exec($_GET you can easily find on github? Hilarious comment thread on hacker news:
This is awful. Shell commands are not guaranteed to be idempotent, people! These should all be of the form exec($_POST, not exec($_GET.
Ringleader claimed to be an IT contractor, got access to bank computers.
Using social engineering to install a remote-controlled keyboard-video-mouse (KVM) switch on bank PCs, the gang managed to transfer millions to outside accounts in two separate jobs in April and July of 2013. They were caught attempting to rob a third bank in September.
Internet Archive lets you play one of the earliest computer games Space War! emulated in JavaScript in the browser.
This entry covers the historical context of Space War!, and instructions for working with our in-browser emulator. The system doesn’t require installed plugins (although a more powerful machine and recent browser version is suggested).
The JSMESS emulator (a conversion of the larger MESS project) also contains a real-time portrayal of the lights and switches of a Digital PDP-1, as well as links to documentation and manuals for this $800,000 (2014 dollars) minicomputer.
The Wall Street Journal was first to report that The Federal Communications Commission will propose new open Internet rules this Thursday that will allow content companies to pay Internet service providers “for special access to consumers.” Under the new rules, service providers may not block or discriminate against specific websites, but they can charge certain sites or services for preferential traffic treatment if the ISPs’ discrimination is “commercially reasonable.” Bye-bye, Net Neutrality, and the internet as we know it.
You’ve gotta watch this Super Smash Bros. Melee documentary that follows some of the top players in the scene—it’s quite good. Accessible, too: you don’t need to be a fox-only no-items final destination type player to enjoy it; they break the game down wonderfully.
Matt & David on Chris Hardwick’s Comic Con Blunder (x)
requested by tennanttardistime
Bonus Chris Hardwick in costume: