Since upgrading to Windows 10 we can't get Office Javascript API running offline in Word. We're running Word build 16.0.4639.1000 64-bit. Previously over last year we've been running the Office Javascript API successfully against Word 2016 (same build), using v1.1.4 downloaded from github OfficeDev.
<script type="text/javascript" src="vendor/microsoft/office-js-1.1.4/dist/office.js"></script>
However the above line no longer works in Windows 10 current Word build. Using online versions works fine:
<script src="https://appsforoffice.microsoft.com/lib/1/hosted/office.js" type="text/javascript"></script>
BUT running online is not an option.
I tried updating to v1.1.8 from github and then downloaded from current microsoft hosted site exactly the files that F12 reports Word Taskpane is loading when the online link is used (office.js, en-us/office_strings.js, ariatelemetry/aria-web-telemetry.js, word-win32-16.01.js).
I've traced the problem to DOM insertion of 2 scripts by the office.js file: the locale strings file office_strings.js and the host file, e.g. word-win32-16.01.js.
The problem is that IE11 appears to block the request. F12 network tab shows a GET for each of these files: for microsoft site, the GETs are normal. For the local server, the GETs display a 200 success 'from cache' with 0ms latency, no headers - and the file is certainly not in the IE cache. Then the script loader function in office.js polls for a timeout period, waiting for its internal flags to be set for these two files. As they aren't loaded, their onload functions that would set these flags aren't called and the script loader eventually times out. For the host file (word-...js) it then raises the error 'MicrosoftAjax.js is not loaded successfully.' and of course, as office.js doesn't have a host file, it doesn't call the Office.initialize() function.
The same problem can be seen in IE11 in the standalone test client I've written, which fails for the file o15apptofilemappingtable.js (loaded by office.js in place of host file and locale strings). The script loader eventually times out in the same way with the same error.
Therefore I believe this is actually a problem with Internet Explorer 11 on Windows 10, rather than the officejs libraries. We are running IE11 11.228.17134.0, up to KB4343205. Not unordinary security settings, no Trusted Sites configured.
The interesting part is that if a client certificate is NOT loaded on the machine running the browser request, even locally-sourced DOM-inserted scripts by office.js load fine and everything works. I've regenerated the original cert with java 1.8 keygen, and verified its definitely SHA256. Unfortunately our app needs the client cert.
I've tried serving the office js files from another machine on the local intranet (same problem) and a diff web server (httpd instead of tomcat) but I think the 0ms latency & wiped headers indicates it's IE11 blocking even before the web server is involved.
I have a VERY TEMPORARY AND FRAGILE workaround which others might be interested in:
- DOM insertion of the script works ok from javascript written directly in the root html file! (This means our taskpane app can still work for multiple office hosts.)
Then just need a small js utility which sets a flag in the script loader returned by OSF._OfficeAppFactory.getLoadScriptHelper().
setMsScriptLoaded(OSF.ConstantNames.OfficeStringsId); setMsScriptLoaded(OSF.ConstantNames.HostFileId);
I'd be very grateful if anybody can offer a different workaround or even a proper solution.
...a few months after this initial post I worked out that the problematic line of code in the office.js script loader is:
script.setAttribute("crossOrigin", "anonymous");
If this line is removed or otherwise temporarily negated, the DOM insertion of local office files works fine, without the need for the workaround above. Any suggestions on another way to configure/enable offine access would be extremely welcome however!