Blockscout: Page renders but never loads data on IOS / FireFox / Safari

[mkrufky]

It has been noted that on IOS Mobile and on OSX (tested on a MacBookPro) that the page will render but data never loads, while the UI displays the "Loading..." animation forever...

Environment

• seen both on IOS mobile and OS/X on a MacBookPro

Steps to reproduce

Open BlockScout in FireFox or Safari on Apple hardware, observe the lack of functionality.

Expected behaviour

BlockScout should function properly on all browsers, across all operating systems. Chrome works properly on OSX, but I havent seen any evidence of it working properly on IOS at all. It does work fine on Android, at least, from what I've seen.

[acravenho]

This is an indication that there is an error installing node modules. Is this running MIX_ENV=dev or MIX_ENV=prod?

If prod, please make sure you run mix phx.digest.

[mkrufky]

It was running MIX_ENV=prod under the docker environment. Please forgive me, but can you describe at which point in the Dockerfile I should run mix phx.digest ?

[acravenho]

This would be run before starting the server MIX_ENV=prod mix phx.server. This creates all the production static assets and places them in a static folder located here: https://github.com/poanetwork/blockscout/tree/master/apps/block_scout_web/priv/

[mkrufky]

Ah, so I should rebuild the container from scratch I suppose? I will do that and report back.

[mkrufky]

This patch does not solve the problem:

--- a/docker/Dockerfile
+++ b/docker/Dockerfile
@@ -35,6 +35,8 @@ RUN cd apps/explorer/ && \
     npm install && \
     cd -

+RUN mix phx.digest
+
 # RUN mix do ecto.drop --force, ecto.create, ecto.migrate

 # USER default

[mkrufky]

Likewise, the following patch ALSO fails to solve the problem:

--- a/docker/Makefile
+++ b/docker/Makefile
@@ -90,6 +90,10 @@ start: build postgres
        @docker run --rm \
                                        $(BLOCKSCOUT_CONTAINNER_PARAMS) \
                                        -p 4000:4000 \
+                                       $(DOCKER_IMAGE) /bin/sh -c "mix phx.digest"
+       @docker run --rm \
+                                       $(BLOCKSCOUT_CONTAINNER_PARAMS) \
+                                       -p 4000:4000 \
                                        $(DOCKER_IMAGE) /bin/sh -c "mix phx.server"

 run: start

[mkrufky]

I also tried this.... maybe the --rm argument is the culprit:

--- a/docker/Makefile
+++ b/docker/Makefile
@@ -87,6 +87,10 @@ endif

 start: build postgres 
        @echo "==> Starting blockscout"
+       @docker run \
+                                       $(BLOCKSCOUT_CONTAINNER_PARAMS) \
+                                       -p 4000:4000 \
+                                       $(DOCKER_IMAGE) /bin/sh -c "mix phx.digest"
        @docker run --rm \
                                        $(BLOCKSCOUT_CONTAINNER_PARAMS) \
                                        -p 4000:4000 \

same behavior, no change

[acravenho]

Let me take some time tonight and tomorrow morning to walk through it. I'll report back.

[mkrufky]

Thank you very much - I really appreciate the help.

[acravenho]

Not Docker but this is what people are using on Azure to launch a BlockScout instance. Not sure if it's any help to you.

https://github.com/acravenho/blockchain/blob/ac-fix-blockscout-install-script/ledger/template/ethereum-on-azure/technology-samples/blockscout/install_blockscout.sh

[dwalintukan]

We are experiencing the same issues with our iPhones and Explorers as well. Android (with Chrome) has been confirmed to be working.

[acravenho]

I'm having a very difficult time replicating this issue. I'm seeing everything working normally. I've asked one of our developers to look into the issue. I'm waiting on a response.

[dwalintukan]

@acravenho If you have an iPhone you can test on testnet.ghuchain.com.

[acravenho]

Thank you. Checking it out now

[mkrufky]

You can also use https://testblocks.ether1.wattpool.net/

[mkrufky]

if it helps, I've updated the Makefile again as follows:

--- a/docker/Makefile
+++ b/docker/Makefile
@@ -90,7 +90,7 @@ start: build postgres
        @docker run --rm \
                                        $(BLOCKSCOUT_CONTAINNER_PARAMS) \
                                        -p 4000:4000 \
-                                       $(DOCKER_IMAGE) /bin/sh -c "mix phx.server"
+                                       $(DOCKER_IMAGE) /bin/sh -c "mix phx.digest && mix phx.server"

 run: start

but I continue to see this at startup:
```Feb 07 08:48:56 systemd[1]: Started Blockscout service.
Feb 07 08:48:56 sudo[11329]: pam_unix(sudo:session): session closed for user root
Feb 07 08:48:56 make[11348]: ==> Checking for blockscout image blockscout_prod
Feb 07 08:48:56 make[11348]: ==> Image exist. Using blockscout_prod
Feb 07 08:48:56 make[11348]: ==> Checking PostrgeSQL container
Feb 07 08:48:56 make[11348]: ==> PostgreSQL Already started
Feb 07 08:48:56 make[11348]: ==> Starting blockscout
Feb 07 08:48:59 make[11348]: ==> ethereum_jsonrpc
Feb 07 08:48:59 make[11348]: The input path "priv/static" does not exist
Feb 07 08:48:59 make[11348]: ==> explorer
Feb 07 08:48:59 make[11348]: The input path "priv/static" does not exist
Feb 07 08:49:01 make[11348]: ==> block_scout_web
Feb 07 08:49:01 make[11348]: Check your digested files at "priv/static"
Feb 07 08:49:01 make[11348]: ==> indexer
Feb 07 08:49:01 make[11348]: The input path "priv/static" does not exist
Feb 07 08:49:07 make[11348]: 2019-02-07T13:49:07.898 application=tzdata [info] tzdata release in place is from a file last modified Thu, 03 May 2018 23:55:14 GMT. Release file on server was last modified Mon, 31 Dec 2018 01:25:12 GMT.
Feb 07 08:49:08 make[11348]: 2019-02-07T13:49:08.719 [warn] The on_load function for module libsecp256k1 returned:
Feb 07 08:49:08 make[11348]: {:error, {:load_failed, 'Failed to load NIF library: \'Error loading shared library /opt/app/_build/prod/lib/libsecp256k1/priv/libsecp256k1_nif.so: No such file or directory\''}}
Feb 07 08:49:09 make[11348]: 2019-02-07T13:49:09.726 application=tzdata [info] Tzdata has updated the release from 2018e to 2018i
Feb 07 08:49:12 make[11348]: 2019-02-07T13:49:12.451 [warn] The on_load function for module libsecp256k1 returned:
Feb 07 08:49:12 make[11348]: {:error, {:load_failed, 'Failed to load NIF library: \'Error loading shared library /opt/app/_build/prod/lib/libsecp256k1/priv/libsecp256k1_nif.so: No such file or directory\''}}
Feb 07 08:49:13 make[11348]: 2019-02-07T13:49:13.851 application=phoenix [info] Running BlockScoutWeb.Endpoint with cowboy 2.6.1 at http://localhost:4000
Feb 07 08:49:14 make[11348]: 2019-02-07T13:49:14.069 application=phoenix [info] CONNECT BlockScoutWeb.UserSocket
Feb 07 08:49:14 make[11348]: Transport: :websocket
Feb 07 08:49:14 make[11348]: Connect Info: %{}
Feb 07 08:49:14 make[11348]: Parameters: %{"locale" => "en", "vsn" => "2.0.0"}
Feb 07 08:49:14 make[11348]: 2019-02-07T13:49:14.069 application=phoenix [info] Replied BlockScoutWeb.UserSocket :ok

...later followed by:

Feb 07 08:49:20 make[11348]: 2019-02-07T13:49:20.092 application=phoenix [info] CONNECT BlockScoutWeb.UserSocket
Feb 07 08:49:20 make[11348]: Transport: :websocket
Feb 07 08:49:20 make[11348]: Connect Info: %{}
Feb 07 08:49:20 make[11348]: Parameters: %{"locale" => "en", "vsn" => "2.0.0"}
Feb 07 08:49:20 make[11348]: 2019-02-07T13:49:20.093 application=phoenix [info] Replied BlockScoutWeb.UserSocket :ok
Feb 07 08:49:20 make[11348]: 2019-02-07T13:49:20.231 fetcher=block_realtime [error] GenServer Indexer.Block.Realtime.Fetcher terminating
Feb 07 08:49:20 make[11348]: * (stop) exited in: GenServer.call(Indexer.Block.Realtime.WebSocket, {:subscribe, "newHeads", []}, 5000)
Feb 07 08:49:20 make[11348]: * (EXIT) time out
Feb 07 08:49:20 make[11348]: (elixir) lib/gen_server.ex:924: GenServer.call/3
Feb 07 08:49:20 make[11348]: (indexer) lib/indexer/block/realtime/fetcher.ex:69: Indexer.Block.Realtime.Fetcher.handle_continue/2
Feb 07 08:49:20 make[11348]: (stdlib) gen_server.erl:637: :gen_server.try_dispatch/4
Feb 07 08:49:20 make[11348]: (stdlib) gen_server.erl:388: :gen_server.loop/7
Feb 07 08:49:20 make[11348]: (stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
Feb 07 08:49:20 make[11348]: Last message: {:continue, {:init, [transport: EthereumJSONRPC.WebSocket, transport_options: %EthereumJSONRPC.WebSocket{url: "ws://127.0.0.1:1196", web_socket: EthereumJSONRPC.WebSocket.WebSocketClient, web_socket_options: %EthereumJSONRPC.WebSocket.WebSocketClient.Options{event: nil, params: nil, web_socket: Indexer.Block.Realtime.WebSocket}}]}}
Feb 07 08:49:20 make[11348]: State: %Indexer.Block.Realtime.Fetcher{block_fetcher: %Indexer.Block.Fetcher{broadcast: :realtime, callback_module: Indexer.Block.Realtime.Fetcher, json_rpc_named_arguments: [transport: EthereumJSONRPC.HTTP, transport_options: [http: EthereumJSONRPC.HTTP.HTTPoison, url: "http://127.0.0.1:1195", http_options: [recv_timeout: 60000, timeout: 60000, hackney: [pool: :ethereum_jsonrpc]]], variant: EthereumJSONRPC.Geth], receipts_batch_size: 250, receipts_concurrency: 10}, max_number_seen: nil, previous_number: nil, subscription: nil, timer: nil}
Feb 07 08:49:20 make[11348]: 2019-02-07T13:49:20.643 application=phoenix [info] CONNECT BlockScoutWeb.UserSocket
Feb 07 08:49:20 make[11348]: Transport: :websocket
Feb 07 08:49:20 make[11348]: Connect Info: %{}
Feb 07 08:49:20 make[11348]: Parameters: %{"locale" => "en", "vsn" => "2.0.0"}
```

[acravenho]

When the production node assets are installed, they should create the priv/static folder.

RUN cd apps/block_scout_web/assets/ && \
    npm install && \
    npm run deploy && \
    cd -

mix phx.digest and the npm run deploy are not working correctly

[acravenho]

I'm aware of the libsecp256k1 on Ubuntu as are many other projects right now. There doesn't seem to be a clear path forward, but this doesn't affect the indexing or rendering of the project at all.

Here is some background info: https://github.com/exthereum/exth_crypto/issues/8

[zachdaniel]

This is working normally for me, just using make start. I'm on safari ios, connected to a blockscout running in a docker container. I tried removing my assets ahead of time, suspecting that they were perhaps not being generated properly, but it seems to be fine.

[zachdaniel]

@mkrufky In safari developer tools I'm seeing this error message when attempting to connect to both of the example blockscouts: testblocks.ether1.wattpool.net and testnet.ghuchain.com .

Refused to connect to wss://testnet.ghuchain.com/socket/websocket?locale=en&vsn=2.0.0 because it does not appear in the connect-src directive of the Content Security Policy.
app.js:140:196670

This seems pretty likely to be the issue.

[mkrufky]

@zachdaniel based on https://stackoverflow.com/questions/41102298/ios-refused-to-connect-because-it-appears-in-neither-the-connect-src-directive-n , sounds like BlockScout should be populating this header.....

[zachdaniel]

Yeah, I think you are correct. I’ll look into it now.

[zachdaniel]

@mkrufky So there is code that builds a CSP based on the host the request was made from. I think there may be some kind of proxy and/or something in cloudflare (which it seems like you may be going through) that is rewriting the host request header that is sent along with the request. The CSP is derived from the host header currently, and what is getting sent back from the server is:

connect-src 'self' ws://localhost:4000 wss://localhost:4000; default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' 'unsafe-eval' https://fonts.googleapis.com; img-src 'self' 'unsafe-inline' 'unsafe-eval' data:; font-src 'self' 'unsafe-inline' 'unsafe-eval' https://fonts.gstatic.com data:;

leading me to believe the host header is being rewritten to localhost:4000 somewhere along the line.

So there are two things:

1.) You might want to look and see if anything is intercepting/rewriting the host header.

2.) I'm not sure if the current behavior of deriving the CSP from the host header is a good idea. Instead, we should derive the CSP from a configuration that gets set on the server side (like an env var listing supported hosts).

[mkrufky]

I am not using CloudFlare, or any cdn service at all..... BlockScout is, however, wrapped with nginx. I believe the issue is:

WebSocket connection to 'wss://testblocks.ether1.wattpool.net/socket/websocket?locale=en&vsn=2.0.0' failed: Error during WebSocket handshake: Unexpected response code: 426

a WS port is exposed, but no WSS port. I don't believe GETH offers WSS functionality. Does this actually work with geth?

[mkrufky]

I'll try manually wrapping ws -> wss using nginx. I found some info here: https://stackoverflow.com/questions/10381412/nginx-config-for-wss

[zachdaniel]

I think you might need a line like this in your nginx config

proxy_set_header Host $host;

[mkrufky]

SOLVED! Fixed "live update does not live update" and "Page renders but never loads data on IOS / FireFox / Safari "

.... I'd like to call it a documentation bug. Andrew pasted a correct nginx configuration on discord today, but it had some stray \ that were screwing up, so I disabled those lines. After re-enabling them and removing the stray \, now it's working <3

[mkrufky]

Despite the fact that it seems to be working now, I continue to see these errors at startup:

Feb 11 19:45:04 make[11951]: ==> ethereum_jsonrpc
Feb 11 19:45:04 make[11951]: The input path "priv/static" does not exist
Feb 11 19:45:04 make[11951]: ==> explorer
Feb 11 19:45:04 make[11951]: The input path "priv/static" does not exist
Feb 11 19:45:05 make[11951]: ==> block_scout_web
Feb 11 19:45:05 make[11951]: Check your digested files at "priv/static"
Feb 11 19:45:05 make[11951]: ==> indexer
Feb 11 19:45:05 make[11951]: The input path "priv/static" does not exist

[acravenho]

Those are not errors. When mix phx.digest is run, it checks all umbrella applications to compile static assets. Only block_scout_web contains such files.

[mkrufky]

I think we can close this, then. It all came down to a bad nginx / wss setup. It might be nice to include the proper nginx setup in the documentation.

[acravenho]

That's great to hear. I completely agree that we should include it in the documentation. I'll create a new issue and reference it here. :+1:

[acravenho]

Issue has been resolved. We're going to add documentation in #1436 and a forum post in #1437

[dwalintukan]

Works great, thanks for the super simple fix @zachdaniel !