Last month (June 2017) was stressful for the general community, our customers and us as the June Security Update from Microsoft included a bug in Internet Explorer that led to a breakage in printing, the impact of which maybe took everyone by surprise.
On the Thursday morning we received a report of printing problems from a customer that they suspected was due to the security update (well spotted them!). Generally our first reaction in these cases is that a change has occurred in Internet Explorer that breaks us and we have to set to and update ScriptX.
However analysis showed that the problem wasn’t that an Internet Explorer change had broken ScriptX but that Internet Explorer was broken when printing HTML in a frame. We quickly made a simple repro of the issue and sent it to our contacts at Microsoft who acknowledged the problem. And so the wheels started turning.
At this point we felt that the issue was probably of limited scope. However as the community – both those who use ScriptX and those who use more manual approaches without ScriptX – started asking questions on a number of community sites about how and why their apps were no longer able to print HTML, it became clear it was a bigger issue. What Microsoft may not have been aware of is (a) the amount of printing of HTML documents that still goes on in the world and (b) that it isn’t ‘leisure printing’ – it has purpose be it from a shipping manifest to medicine bottle label. So when it doesn’t work, it matters.
It quickly became apparent that Microsoft would be unable to deliver a resolution in a matter of days, so on the Friday we started a deep-dive analysis of what was actually going wrong and determined that we could develop a work-around to “fix” the errant behaviour. The updates we had made failed our internal QA so it had to wait until the Monday for us to release a hotfix : v8.0.2.
v8.0.2 was OK, it fixed a high percentage of our customers and got them working again. However, it didn’t fix the issue in a number of scenarios. It took us two more days and two more hotfix releases, v8.0.3 and v8.0.4, to finally nail all scenarios and achieve 100% coverage. Along the way we’ve learnt quite a bit more about the types of document environments ScriptX is used in.
A concern had always been to try and implement the fix in a way that would be future proof against a fix from Microsoft – i.e. our ‘fix’ code wouldn’t run when it didn’t actually need to and so not absolutely require another ScriptX update deployment to work with an updated Internet Explorer. We had to relax the way our fix was done in order to resolve additional scenarios and this left us slightly more vulnerable to breaking when an Internet Explorer fix was released. Fortunately we have found that ScriptX versions 8.0.2, 8.0.3 and 8.0.4 all work with the fixed versions of Internet Explorer.
A month on and the rapid response fixes from Microsoft and the latest round of security updates have fixed Internet Explorer on all OSs, so that the hotfixes from us are no longer needed.
Finally we get to what this post is all about.
ScriptX v8.0.5 reverts the changes that we made in hotfixes 8.0.2, 8.0.3 and 8.0.4. Its also fixes some regressions that were introduced in hotfix 8.0.1 (full details here).
Should you deploy this update?
We strongly recommend you deploy this update if you have deployed ScriptX 8.0.1 as the failure to recognise print completion in 8.0.1 can have a negative impact on user experience.
If you deployed any of 8.0.2 through 8.0.4 in order to work-around the issues with printing framed content then deployment of this update is optional.
