[resolved] Diagram Application Extension - not working - need help debugging

Help / Discuss
,
#1

I’ve installed the draw.io Diagram Application extension and I’ve run into the following problem.

When I try to create a diagram page, I get a spinner icon that goes on endlessly. I’ve tried using Windows/Firefox, MacOS/safari and the result is the same.

Does anyone have any suggestions as to how I could debug this problem so I can get the diagram application extension to work?

  • server: xwiki 10.1, tomcat8, ubuntu 16.04
  • client: mac osx 10.12 & safari, windows 10 & firefox latest version.

The wiki is accessed via an nginx proxy and everything else seems to work correctly.

I don’t see any relevant errors in the tomcat catalina.out logs.

Any insight or advice would be greatly appreciated.

#2

You should check the JavaScript console from the browsers’s developer tools. See if there are JavaScript exceptions logged. You can also check the Network tab (from the same developer tools) to see if there are failed requests (e.g. 404) for the Diagram Application resources (JavaScript, CSS).

You should also clear the browser cache to make sure you don’t have outdated Diagram Application resources cached in the browser.

Hope this helps,
Marius

#3

Just tested the application on xwiki 10.1 Debian without reverse proxy and launching the app works. Clients were FF and Chrome latest on Win 10.
Did you already have a look in the browsers web development tools (reachable via F12 key on windows)?
I’d either expect that some of the resources can’t be loaded (see network tab) or that a script fails (see console tab). Investigate in this order, because a script that fails to load may cause scripting errors.

Did you have a look in the nginx logs if there are any errors or requests that it fails to serve?
Can you also try to bypass nginx and see if it works then?

Hope that helps?

#4

Good suggestions. Let me try all those and see what I discover.

#5

hmm…

I just tried it in chrome and went to the server directly rather than through the proxy and it worked first try, so the problem is clearly on my side.

Now I tested it with chrome going through the proxy - and spinner…

So now I know where and how to look.

Thanks!

#6

You guys are good.

Refused to execute script from ‘https://wiki.proxy.domain/xwiki/webjars/wiki%3Ait/mxgraph-editor/3.7.2/mxGraphEditor.min.js’ because its MIME type (‘text/x-matlab’) is not executable, and strict MIME type checking is enabled.

#7

So the problem comes down to two parts:

1/ my nginx ssl configuration has the following configuration as part of the ssl hardening

add_header X-Content-Type-Options nosniff;

2/ The javascript used by the draw.io application https://wiki.real.server/xwiki/webjars/wiki%3Ait/mxgraph-editor/3.7.2/mxGraphEditor.min.js is served from tomcat with the content type set to

content-type: text/x-matlab

This results in an error because the text/x-matlab is actually not considered an executable type and the nosniff option tells the browsers to enforce strict mime checking.

So, the workaround is to weaken the security of the nginx installation.

The real question is, why is the mxgraph-editor/3.7.2/mxGraphEditor.min.js file being served from tomcat with the wrong file type?

Is this an error in the mxgraph-editor package?

#8

WebJar resources (JavaScript, CSS, etc.) are served by https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-webjars/xwiki-platform-webjars-api/src/main/java/org/xwiki/webjars/internal/WebJarsResourceReferenceHandler.java which extends https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-resource/xwiki-platform-resource-servlet/src/main/java/org/xwiki/resource/servlet/AbstractServletResourceReferenceHandler.java#L177 which, as you can see, uses Tika to detect the content type of the served resource. So it looks like

TikaUtils.detect(resourceStream, resourceName)

returns text/x-matlab for mxGraphEditor.js but I don’t know why. The detection takes into account both the file name and the file content. In this case it seems there is something in the content of mxGraphEditor.js that makes Tika think the file is a `text/x-matlab``.

#9

So, it is a bug in the tikia matlab parser that causes it to recognize the minified js as a matlab file.
https://wiki.real.server/xwiki/webjars/wiki%3Ait/mxgraph-editor/3.7.2/mxGraphEditor.min.js

asking the non minified version results in the correct document type.
https://wiki.real.server/xwiki/webjars/wiki%3Ait/mxgraph-editor/3.7.2/mxGraphEditor.js

Right, let me go submit a bug report to the tiki project.

Thanks Marius.

#10

Reported: https://issues.apache.org/jira/browse/TIKA-2608

The problem is resolved in the 2.0.0-SNAPSHOT build.

The problem is unresolved in the 1.18 branch build as of this time.

#11

It may be useful to know that I get the spinner issue but it seems to be for a different reason.

I am running XWiki Debian 10.4 (standard flavour) and using Diagram Application 1.2 running on Linux Mint 18.3 (Sylvia).

I am using Firefox 60.0.2 and if I try to view a diagram using: http://localhost:8080/xwiki/bin/view/Test%20Diagram I get the spinner and the following in the JavaScript console:

Loading failed for the <script> with source “http://localhost:8080/xwiki/webjars/wiki%3Axwiki/mxgraph-client/mxClient.min.js”.
Test%20Diagram:1
Error: Script error for "mxgraph-client"
http://requirejs.org/docs/errors.html#scripterror
require.min.js:7:290
Loading failed for the <script> with source “http://localhost:8080/xwiki/webjars/wiki%3Axwiki/mxgraph-editor/sanitizer/sanitizer.min.js”.
Test%20Diagram:1
Error: Script error for "sanitizer"
http://requirejs.org/docs/errors.html#scripterror
require.min.js:7:290
Error: Load timeout for modules: draw.io.viewer,mxgraph-viewer
http://requirejs.org/docs/errors.html#timeout

However, if I try to access the diagram using http://xwiki-br-test:8080/xwiki/bin/view/Test%20Diagram/ the diagram is displayed perfectly.

Notably, if I use Chrome Version 67.0.3396.87 and try the same localhost URL then it works perfectly.

So the only difference is that on Firefox it doesn’t work using localhost, but it does using the hostname.

Hope this helps.

Archie

#12

Hi @pdwalker,

unfortunatelly i have the exact same Problem as you befor 2 years (no Draw.io Functionallity in XWIKI behind a nginx Reverse proxy).

I Currently Run on Tomcat 7 on my XWIKI System. Can you confirm, that the Upgrade to Version 8.5 will fix the Problem?

Thank you for your help/Info.

With best regards

Knight01

#13

Hi @Knight01,

I no longer have this problem in the xwiki 12.8/tomcat 9/open jdk 1.8.0 under ubuntu 18.04 behind an apache 2.4.29 reverse proxy using the ajp connector

#14

Hi pdwalker,

thank you for your Info. I upgraded yesterday my Tomcat to version 9. But the Problem will not disapear…

Unfortunatelly i have no clue where i can search further…