RocketChat / RocketChat/Rocket.Chat

SVG icons in sidebar/toolbar don't render on current desktop Firefox for Linux, ?https issue?

Open
#10,664 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area: ui/ux
Dominant language
TypeScript
Stars
46.1k
Forks
13.9k
Avg merge
3d 3h
Merged PRs (30d)
130

Description

Description:

When logged in to Rocket.Chat hosted via Apache reverse-proxy over https, the six icons in the toolbar (for search, directory, etc.) don't appear.
Client browser is Firefox 52.7.3 ESR 64 bit on Linux.

It does work on Firefox 59.0.2 on Android and Chromium on the same Linux machine as before.
So "further debugging" below. It appears to be an interaction of the ESR version of Firefox with the https proxy.

Server Setup Information:
  • Version of Rocket.Chat Server: 0.64.0
  • Operating System: Linux (Debian stretch 64 bit)
  • Deployment Method(snap/docker/tar/etc): tarball
  • Number of Running Instances: 1
  • Node Version: 8.9.4
  • mongoDB Version: 3.2.11

Rocket.chat's being served via an Apache reverse-proxy setup on a HTTPS server.

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/rocketchat$
RewriteRule /rocketchat https://the.host.name/rocketchat/ [R,L]
RewriteCond %{REQUEST_URI} ^/rocketchat/(.)
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.
) ws://localhost:3000/$1 [P,L]
RewriteCond %{REQUEST_URI} ^/rocketchat/(.)
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule /(.
) http://localhost:3000/$1 [P,L]
ProxyRequests Off
ProxyPassReverse /rocketchat/ "http://localhost:3000/"

Steps to Reproduce:
  1. Set up the server (as above, tarball, Apache reverse-proxy, rewrite rules).
  2. Login.
Expected behavior:

See the various icons in the toolbar, e.g., search, directory, ...

Actual behavior:

Not seen.

Further debugging:

This looks very similar to issue 7980.
The problematic browser works fine if connecting via http (not https) directly to port 3000.
So I suspected something weird around those differences.
Experimentation by using Firefox's debugger to change the href links in the svg/use elements found that by having the full https://the.host.name/home#icon-whatever was the problem. Replacing this with home#icon-whatever works.

Based on kimgb's script in issue 7980, I found that this fixed it (at least, I haven't found it broken again yet):
$(document).ready(function(){
$("svg > use").map(function(){
var svg_string = $(this)[0].href;

if (svg_string.baseVal.startsWith("https://the.host.name/home#")){
  svg_string.baseVal = svg_string.baseVal.replace("https://the.host.name/home#", "home#"); 
  svg_string.animVal = svg_string.animVal.replace("https://the.host.name/home#", "home#");
}

});
})

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the missing SVG toolbar icons with Firefox 52.7.3 ESR on Linux through the Apache HTTPS reverse proxy, comparing direct HTTP access and the SVG href values described here. Review issue 7980 and the sidebar/toolbar icon entry points; done means the search, directory, and other toolbar icons render in the affected setup without the URL-specific workaround.

Written by the indexing model from the issue text.

Assessment

Tech stack
apache, javascript
Domain
frontend, web-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.