In ServiceWorker mode, be more consistent on spinner visibility

[mossroy]

Following the discussion in #417 (comment) , there's something inconsistent in the UI when in ServiceWorker mode : when opening an article from a search or any other button of the UI, a spinner is displayed.
But the spinner is not displayed when the user clicks on a hyperlink inside an article, to go to another one.

We should either never display the spinners (in ServiceWorker mode), and rely on the user-feedback given by the browser itself. Or always display them (with some quirks like in #155)
I'd be in favor of never displaying them : that would need to add "if" statements in several places of app.js, to display the spinner only if we are in jQuery mode.

[Jaifroid]

[Cross-referencing our existing issue for this: #135 ]

Below is a summary of what happens in each major browser when clicking on a link in SW mode. To test, I am using the article "France" from full English Wikipedia, clicked through from the article "Paris".

• Edge: No spinners or native indication that the browser is busy, but the requested page opens in <1 second with no stylesheets applied, and elements are visually added to the screen or rearranged over the next ~4 seconds until the visible area is fully composed.

• Firefox Quantum: No indication of any activity for ~1 second after clicking on the "France" link, then some small static text appears bottom left of the browser window: "Read localhost", and the reload icon top left of the browser window changes from a circle arrow to a cross. Meanwhile, the "Paris" article remains static on the screen. After a further ~4 seconds the new article suddenly appears, with the visible area fully composed. ~0.5 seconds later "Read localhost" disappears and the cross icon turns to a circle arrow.

• Chromium 66.0: On clicking the link, the screen within the iframe blanks completely in ~1s, and a few milliseconds later some small static text appears at the bottom left of the browser window: "Processing request...". After a further ~3 seconds the blank screen is replaced by the "France" article, with the visible area fully composed. "Processing request..." remains bottom left for ~6 seconds and then disappears.

My opinion (trying to think like an end user)

I found the Firefox feedback to be the least informative, in fact I found it disconcerting, because it is very hard to notice the static message, which appears inside the same area that shows the target of the link when you hover over it (I did not notice it or the changed static icon until I had run the experiment a few times), and since the "Paris" page remains completely static on the screen, it appears that the link has not worked. In fact, the first time, I thought the click hadn't registered, and I clicked again, which delayed the appearance of the next article.

The Chromium feedback is more helpful than that of Firefox, because at least something noticeable happens on clicking the link, i.e., the visible area goes blank. Again, I did not notice the message for the first few times running the experiment. However, I found staring at a blank screen with no other obvious information about what was going on somewhat disconcerting, and as a "naïve" user, I would wonder if something had gone wrong.

The Edge "feedback", is, ironically (because it seems unintentional), the most "helpful" in that as a naïve user I would almost immediately see that the click has worked. However, over time it would appear unprofessional that the new article appears with no styling at first, and the novelty of watching it rearrange itself would turn to annoyance.

I am using a top-end machine with a powerful processor. Multiply the above timings for lower-end machines and mobile devices, and I think it is obvious that there is a problem. None of the browsers are satisfactory, and we should work towards a unified experience, in my opinion. I would be in favour of matching the experience we currently provide in jQuery mode, because it provides immediate feedback, appears far more professional in all three browsers, and is consistent throughout the app (and amongst the browsers).

It is not a priority now, because end users are warned off using Service Worker, but it would become a priority when we decide to implement #196.

[Jaifroid]

I think we solved this issue. We don't show assets caching, but we do show the spinner when a user clicks on a link in SW mode. Closing.