Page MenuHomePhabricator

Display an error message when users do not have JavaScript enabled
Open, NormalPublic1 Story Points

Description

When a user goes to:
https://tools.wmflabs.org/interaction-timeline/
and they do not have JavaScript enabled, they will get a blank white page.

We should use the <noscript> tag to display an error message to the user informing them that JavaScript (at this time) is required to use the timeline.

Alternatively T185786: Support no-JS

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 26 2018, 11:07 PM
dbarratt updated the task description. (Show Details)Jan 26 2018, 11:15 PM
Niharika triaged this task as Normal priority.Thu, Aug 8, 6:37 PM
Niharika set the point value for this task to 1.

would we rather:

  1. Enable server-rendering which will allow us to display the message in the user’s language. This will require splitting the tool into two tools (which is trivial, imho, and can remain in a single repo if we want): https://lists.wikimedia.org/pipermail/cloud/2019-August/000774.html
  2. Leave the app as “static” and display the message in all languages?
aezell claimed this task.Wed, Aug 14, 7:48 PM
dmaza added a subscriber: dmaza.Thu, Aug 15, 4:27 PM

would we rather:

  1. Enable server-rendering which will allow us to display the message in the user’s language. This will require splitting the tool into two tools (which is trivial, imho, and can remain in a single repo if we want): https://lists.wikimedia.org/pipermail/cloud/2019-August/000774.html
  2. Leave the app as “static” and display the message in all languages?

Splitting the tool into two services increases complexity and adds more points of failure. I can't really justify doing that only to display a nojs message. If we were to support a nojs experience maybe it would make sense(?). The alternative you are suggesting which is to display a message in all languages might be a bit overwhelming for the user to look at I think.

I vote for doing something like <noscript><meta http-equiv="refresh" content="0; url=/no-js-version" /></noscript>. That allows us to redirect to a php page with a translated message saying that we don't support a nojs experience.

I vote for doing something like <noscript><meta http-equiv="refresh" content="0; url=/no-js-version" /></noscript>. That allows us to redirect to a php page with a translated message saying that we don't support a nojs experience.

I think that's a bit gross. I would honestly rather just leave that English-only than do that.

We get other benefits from server-rendering (mostly performance related though) and it's pretty trivial to do this.

dmaza added a comment.EditedThu, Aug 15, 6:46 PM

I think that's a bit gross. I would honestly rather just leave that English-only than do that.

Do you care to expand on this? I don't think "gross" is a valid argument

Two services just to support a message is technically a bad decision . It adds overhead, complexity, more dependencies, etc. In general it will be more work; things like the dev stack would need to be updated, server configs will need to adjust. Splitting into two services is not a great solution to this particular problem and it is an overkill in my opinion.

I like the redirect to a PHP page with translations. Simple, incremental, and easy to change later should we want to do something fancier because we want more of a NoJS experience.

Y'all should see what @Tchanders is working on before throwing a ton of code at this. It's cool.