Blogroll code development search

Microsoft Edge, ungooglability and a new class of bugs

Microsoft definitely has a naming problem. .net core was one thing, but calling a browser Edge was just trolling developers. Try searching for “Edge CSS” or “JavaScript Edge”. It’s a lesson in frustration, which means the bugs in the new browser are extra painful to debug because it’s that much harder to find the blog posts and Q&A for the last person to fix the problem.

And Edge doesn’t behave like IE, or Firefox, or Chrome. I’m sure Microsoft, like the other vendors, are updating OSS frameworks to help them target Edge, but there’s still a lot of Javascript and CSS that breaks silently, so no Console logs to help, no odd numbers in the calculated CSS, and no hacks to persuade Edge that it can render just like the big browsers.

I want to like the browser, I really do. Anything that brings the end of IE closer has to be welcomed, but even after the Anniversary update of Windows 10, it’s far from ready. If I try to open IIS failure logs in Windows 10, it opens up IE, and displays with the correct CSS, and then tells me I should use Edge, where the CSS is broken. It’s frustrating as a user, and as a developer. It’s an alpha product, and it should have been treated as such. Give it to devs, allow power users to opt in, and iterate it. Microsoft still needs to learn what it means to develop in the open.


Unfortunately the problem is then compounded by Microsoft’s documentation problem. For all the faults of IE, at least Microsoft had a good reputation for documentation at the height of MSDN. Unfortunately, MSDN is starting to decay, and there’s a number of conflicting alternatives springing up. For us developers, the seemingly preferred route for latest information is blog posts (or the comments thereon – which were the only source of information for a knotty Docker problem we had), but there’s also GitHub, and the occasional update to the existing MSDN documentation suite.

Microsoft seem to be trying to frustrate developers. Especially when they have evolving, and conflicting APIs (I’m looking at you Azure, and the Python vs PowerShell vs Node APIs, and the Portal experience). The documentation experience at Microsoft feels like the Google UI experience before Material Design. And it needs a similar overhaul.

I love seeing Microsoft trying to be more open and I see it working, to a certain extent, in the C# and .Net space, aside from the .Net Core RC release cycle chaos. They’ve come a long way from the days of alt.Net (although I agree that we need to recapture that passion, both for the sake of new developers, and for the sake of keeping Microsoft in check), but they’re in danger of alienating developers once more with the confusion, and the inconsistencies within certain platforms.

In that context, removing project.json and keeping .csproj was the right decision. One clear and consistent path. Now go and apply it across the board.

code development

Excellent Export, IE and Security

Following on from supporting large Client-side spreadsheets in Chrome, I’ve extended my pull request to also support IE, which uses its own proprietary Javascript method. Because, Microsoft.

And all was good with the world.

Until a Microsoft update broke HTML-formatted XLS files. Because, Microsoft. If you support XLS downloads on your site, and your users are getting a blank Excel window when they try and open them, thank Microsoft, and a security fix. Then go back to using CSV. Or ODS.

Thanks Microsoft.

code development

Excellent Export and the Chrome URL limit

One key difference between junior and senior developers is that when they encounter a bug, senior developers are much more likely to blame themselves before others, because experience moves you up the Dunning-Kruger curve.

I was given a bug report recently where Chrome was unable to download a particular spreadsheet, and IE didn’t work either. Other spreadsheets worked OK. It was fairly obvious that one feature of this spreadsheet was the likely candidate : it was by far the largest spreadsheet in the system.

I tried to recreate the bug, and I use Firefox, because I prefer the developer tools. And the spreadsheet download worked as expected. So it’s a difference between browsers. It might still be my fault, but it’s looking less likely.

The library we used for the export is a Javascript library called excellentexport, which converts an HTML table into an Excel-compatible spreadsheet. It uses the data: URI scheme to encode the spreadsheet directly into the page, so that the spreadsheet can be generated entirely server-side. Internet Explorer does not support data: so displays the link, but clicking on it has no effect. Chrome and Firefox both support it, but it turns out Chrome reduced the URI limit from (what I think is) 256Mb to 2Mb, and I wasn’t able to see why. This originally caused the tab to crash, and still can under the right conditions, but for URIs just bigger than 2Mb (in our case 3.5Mb), the click is processed, but the data URI is rendered empty, so a null file is downloaded.

This can be a tricky one to diagnose, hence this post. If you ever encounter this, the solution is to switch to CreateObjectUrl, which is supported in all recent browsers, including Edge, but not IE (but as it doesn’t support data: you’re not losing out there). I’ve submitted a Pull Request to excellentexport demonstrating the change required. Worth remembering if you ever need to create a download link client side.