In ServiceWorker mode, set the iframe src to display articles.

[mossroy]

Instead of calling displayArticleInForm like in jQuery mode.
I also removed some tests on jQuery/ServiceWorker modes in displayArticleInForm, as this function is now only used in jQuery mode.
And I renamed it to displayArticleContentInIframe

Fixes #382

[mossroy]

I've tested on Firefox 60 and Chromium 66, in ServiceWorker and jQuery modes, with various ZIM files (including stackoverflow.com_eng_all_2017-05.zim).

I also removed some tests on jQuery/ServiceWorker modes in displayArticleInForm, as this function is now only used in jQuery mode. And I renamed it to displayArticleContentInIframe.

[Jaifroid]

I've tested in ServiceWorker and jQuery mode in Edge, and in jQuery mode in IE10. All working fine on quick tests. I noticed the spinner sometimes doesn't hide until the images have finished loading (in ServiceWorker on Edge). It's quite accurate in a way, because it shows the content is still loading, but it's a change (I think). (It doesn't occur in jQuery mode.)

[Jaifroid]

I realize the code that provides the Service Worker with the content does its own resolveRedirect, but wouldn't it save a hop if we allowed this redirect code to run for both modes (jQuery and ServiceWorker) here, then set the iframe's src to the dirEntry.namespace + url of the new dirEntry? Maybe it's unlikely we'd actually encounter a redirect here? Anyway, just a thought.

[mossroy]

Yes, it would certainly work and speed up a little bit.
It's completely possible to encounter a redirect here.
On the other hand, we would "only" save the binary search done by getDirEntryByTitle.
And we had here the opportunity to do things exactly the same between an article opened after a search (or a random search, or the main article), and an article opened while browsing (after a click on a hyperlink). If we handle the redirection differently, we re-introduce a little difference.
I'm torn between doing it or not (or doing it later). Maybe we should benchmark it?

[Jaifroid]

It's very minor. I suggest doing it later if we find a need. If it saves anything, it would be a near-instantaneous lookup. I tried hitting the random button several times and typing misspellings of names into search several times, and I could never get the isRedirect code to fire in the code that provides the Service Worker with content.

[mossroy]

OK I created #384 for that, let's leave this portion as it is, for now.

[Jaifroid]

Here's an example of the spinner still showing while images are being loaded, in Service Worker. I'm not familiar enough with Service Worker to remember if this is the standard behaviour in that mode. (Sorry for the milkiness of this image, I put a breakpoint to be sure I could screenshot the area. Also, typo was deliberate, as I was trying to trigger the .isRedirect code, unsuccessfully!)

[Jaifroid]

PS The code does significantly improve the speed of display of the homepage of the huge Stackexchange ZIM in Edge in ServiceWorker mode.

[mossroy]

Regarding the spinner issue, I don't reproduce it on Firefox or Chrome.
We call $("#readingArticle").hide(); in the onload event, so it's normal that it disappears after the page is completely ready. But it's also at this moment that we call $("#articleContent").show();, so the article should not be visible before we hide the spinner...
Maybe Edge makes the iframe visible as soon as we set a new src to it?
In any case, both behaviors look acceptable to me.

Regarding the ServiceWorker mode in general, there are many things that should be easier and faster to achieve with it, using the browser capabilities instead of reimplementing things ourself. That's why I'm willing to focus on it for the next hackathon, in order to (hopefully) make it the default mode (when available on the device/browser). It does not mean we would drop jQuery mode support, because it's still necessary in many contexts.

[mossroy]

Can I merge this PR?

[Jaifroid]

Yes, looks good to me!