Galaxy: Rendering images in installed tools broken for Galaxy served from subdirectory using 'proxy-prefix'

[pjbriggs]

Following up an upgrade of our production Galaxy from 16.07 to 17.05, we've observed that rendering of images in the 'help' sections of installed tools no longer works correctly when serving Galaxy from a subdirectory (i.e. using proxy-prefix).

Using this configuration, for tools installed from the toolshed, <img> tags are generated but the alt text is displayed rather than the images themselves:

• Install e.g. the Subtract the intervals of two datasets tool (https://toolshed.g2.bx.psu.edu/repository?repository_id=b7e9d20e8c48e333)

• Load the tool: the generated HTML for the tool help image appears as:

  
  :before
  

• But the browser only renders:

  

If the Galaxy configuration is updated to serve from the top level (i.e. no proxy-prefix) then the images appear as expected, so this appears to be entirely related to the use of the proxy-prefix feature.

Some other observations:

• The problem is not seen in the previous Galaxy version 17.01 (i.e. images display correctly regardless of proxy-prefix).
• The img tags generated by both 17.01 (working) and 17.05 (broken) are very similar, except that the hash in the src path is different, and for 17.01 there is no :before or closing </img> tag.
• Editing the img src attribute to insert the proxy prefix (e.g. via 'inspect element' in Firefox) causes the image to render correctly.
• Using git bisect, the problematic behaviour can be seen to appear with commit id 6e32b0f7c119ca6c3d54a761e64f49fe6a7f8280 (and more specifically with changes to the file static/scripts/bundled/analysis.bundled).
• We're running Galaxy behind nginx with multiple paste-based processes, however the same behaviour is observed using uwsgi processes.

Can someone suggest a fix or workaround to make the images render correctly when using the proxy-prefix mechanism?

[jmchilton]

This looks like a regression that needs to be fixed and back ported to 17.05 - for that reason @mvdbeek I'd recommend removing the 17.09 tag - it seems independent of 17.09's release I guess.

Ping @guerler - are you aware of any routing or tool form change that would have caused this?

[pjbriggs]

In this configuration we've also observed that when a job is started, the associated datasets in the history panel fail to automatically transition from grey/started to yellow/running - it requires a manual history refresh. (Conversely, transtitioning to green/finished or red/failed does seem to happen automatically). I don't know if this is a routing issue related to this issue however.

[pjbriggs]

Gentle nudge: this is still a problem for release_17.09, and essentially renders the inline documentation for e.g. deepTools completely useless. Any suggested fixes or workarounds would be appreciated, thanks.

[dannon]

@pjbriggs I'm trying to look into this and the subtract tool indicated seems to be working for me. Just setting up a proxy-prefix of /galaxy should reproduce it, right?

(edit: nevermind reproduced it; when just using proxy-prefix and continuing to talk to the galaxy process it actually works, but tossing nginx in the mix configured with the /galaxy prefix as well caused the error on my end)

[dannon]

Ok, made progress on this. The problem is that the router root isn't pushing a trailing / back onto the proxy prefix, which causes the relative image links to fail.

[pjbriggs]

Hi @dannon thanks for taking a look, should I give the changes in PR #5218 a try on our local instances?

[dannon]

@pjbriggs Sure, if you'd like!

[pjbriggs]

@dannon I've tried them on our instances here and they work perfectly - thanks so much for looking into this! I've left a note on the PR to confirm that they work for us too. Really appreciate the fixes!

[dannon]

@pjbriggs Thanks for testing it, glad it works!

[martenson]

On latest dev, with

galaxy.ini

[filter:proxy-prefix]
prefix = /galaxy

nginx.conf

        location /galaxy {
            proxy_pass http://galaxy_app;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

I see this in the DOM

<img alt="admin_toolshed/static/images/14b1e11af07c2530/gops_intersectOverlappingIntervals.gif" src="admin_toolshed/static/images/14b1e11af07c2530/gops_intersectOverlappingIntervals.gif">

and it renders fine

What am I missing?

[dannon]

(xref discussion in #5218 re: reproducing it)

[martenson]

I was able to reproduce and the naive approach below seems to fix it in my testing.

```diff
diff --git a/client/galaxy/scripts/mvc/tool/tool-form-base.js b/client/galaxy/scripts/mvc/tool/tool-form-base.js
index 058ba302c4..a6cd865535 100644
--- a/client/galaxy/scripts/mvc/tool/tool-form-base.js
+++ b/client/galaxy/scripts/mvc/tool/tool-form-base.js
@@ -245,6 +245,9 @@ export default FormBase.extend({
.addClass("ui-form-help")
.append(options.help);
$tmpl.find("a").attr("target", "_blank");

• _.each($tmpl.find("img"), img => {
• $(img).attr("src", Galaxy.root + $(img).attr("src"));
• });
  return $tmpl;
  },
  ```

[dannon]

@martenson That's a slower, less robust fix, in an already-slow tool form. We can (and should) just make backbone work correctly for us at zero cost. If a library is broken, we should fix it and upstream the change when we can. In fact, several people have tried to do this for Backbone, but the community there prefers the non-trailing slash and didn't accept a patch to make it configurable.

Your concern about manipulating dependencies makes sense on the server side, where we operate in varied environments where, for example, admins may have preinstalled particular dependencies on their own. On the client, though, we control and ship 100% of everything, including the extra libraries.

[martenson]

edit: reposted to the correct thread: https://github.com/galaxyproject/galaxy/pull/5218 - sorry