Scatter Plot Background Images not Appearing in IE11 through IIS FastCGI Setup in Production

Dash Python
1

I’ve set up a multi-app/page Dash application which runs perfectly well through the development Flask server and Waitress (without setting up a Reverse Proxy yet) but I’m struggling to get the last piece of the puzzle working via FastCGI (v3.0.0 downloaded from the latest repository) on IIS8.5 (on Windows Server 2012 R2).

There are two issues:

  • In IE11 and Chrome (both updated to the latest versions from July 2018), the first page that the user hits requires a refresh; sometimes the app gets stuck in the 'Loading… state and sometimes it delivers a failed to load dependencies error. After a refresh almost everything (20 plots plus 2 data tables split over 5 pages) loads correctly.
  • The second issue (probably the most important as this gives the customer the key capability they are looking for), only in IE11, is that the background images I want to embed into a scatter plot are not rendered. Examining the IE11 console output/coding shows that the image HTML tags are missing from the Cartesian Layer of the plot:

js-plotly-plot > plot-container plotly > svg-container > main-svg > cartesianlayer > subplot xy > layer-subplot > imagelayer > image

In Chrome (and IE11 using Flask/Waitress) the image tag contains a base64 encoded string that represents the image; however in IE11 with my production configuration the tags are empty.

A few notes:

  • We have not been able to use the Plotly/Dash production deployment server options due to company restrictions, hence going it alone with this.
  • Apache or Linux based approach cannot be used due to company restrictions.
  • Chrome cannot be used in Production environment due to company restrictions and IE11 is the only option.
  • HTTPS with a valid SSL certificate is being used.
  • CSRF Protect has been set to False.
  • All interactive charts load correctly.
  • Logging/Print statements have confirmed that the correct paths to images are correct.
  • Attempts to access the images via direct links in the browser are successful.
  • Deletion of cache on the client side and compatibility view settings have been investigated but have not proven to be successful.
  • I have attempted to base64 encode images and instruct them to be decoded, as well as sending a direct link, but this has not been successful.
  • The structure of the multi-page app follows the instructions in the Dash documentation (big thanks to @chriddyp and the person that has written all of the documentation).

Next steps:

  • Update Dash and dependencies to latest versions (I have everything as of early February, version 0.18.1).
  • Investigate the Reverse Proxy option with Waitress (this is not what we want to do in Production but we may be forced to do it).
2

I’ve now updated to the latest versions of Dash and this has not fixed this issue (but it doesn’t appear to have introduced any new issues at least):

  • dash v0.23.1
  • dash-core-components v0.26.0
  • dash-html-components v0.11.0
  • dash-renderer v0.13.0

I’ve also tried using the Scattergl plot type but this has just improved the pan speed/reduced glitches when moving around the plots (this is understandable as the background image would still be introduced in the SVG layer and not WebGL). Scattergl introduced a minor issue which was that tool tip colours were not automatically related to the colour of scatter points, but instead coloured black. I’ve reverted back to using go.Scatter instead.

Unless anyone else has any ideas on what could be an issue server side using wfastcgi and IIS, or IE11 settings (I’ve already tried enabling/disabling compatibility mode and turning caching on/off) then i’ll have to look at a different approach.

3

I’ve managed to fix the 2nd issue mentioned in my original post by rolling back to a very basic app and testing base 64 encoding of images using their FULL Windows path. Using this approach in my production code solved the problem; however, I now have some paths defined using the convention ‘/static/resources/x1.csv’ and others using the convention ‘D:\Websites\Dashboard\static\diagrams\image.png’. This is annoying but at least a workable solution. What’s most annoying is that the images are directly accessible using the https://server/static/diagrams/image.png link; just not accessible by IE11 without explicit base 64 encoding of the Windows path.

The first issue I have with ‘Error loading dependencies…’ or stuck in a ‘Loading…’ state on the first page hit is still proving to be a problem in both IE11 and Chrome. I don’t really want to put this out in Production with this issue as we’ll have an immediate problem in User Acceptance Testing so any suggestions on this would be useful. For reference I have used the serve_locally options for scripts and CSS (CSRF Protect is also disabled).