Release a version 2.5

[mossroy]

I think we have implemented a few significant improvements, at least :

• video playback capability (including subtitles) in both SW and jQuery mode
• javascript support (in SW mode), and noscript tag support (in jQuery mode)
• and some other fixes and improvements

It might be worth a new release?

[kelson42]

@mossroy That said, it looks like that the milestone if far from being over... But I support to release often, in particular if a few important features are newly available.

[Jaifroid]

I agree that this release is important enough to do it ahead of schedule (yay!). It makes a whole class of ZIMs usable (those with video).

[mossroy]

I also think we have enough improvements to make a release.
I'll update the github milestones, to rename the existing milestone 2.6 to 2.7 (and do the same for the following ones), and move the remaining issues targeted on milestone 2.5 to a new 2.6 milestone.

It's probably necessary to update the README and the about section to reflect the new ZIM compatibilities of this version, before doing the 2.5 release.

[mossroy]

Second thought, I'm not sure we should update README and about section about new ZIM compatibilities, at least for now.
Because the lack of javascript support in jQuery mode (#152) prevents us from saying we really support ted, dirtybiology etc : the videos can be read, but the home pages don't. So it's more difficult to access them. @Jaifroid is working on that but it's complicated and/or ZIM-specific.
And jQuery mode is still the default one. Until I implement #196, we do not switch to SW mode automatically. And it's still not supported in Firefox extensions.
In SW mode, ted, PheT and dirtybology are truly supported, but I'm not 100% sure they will work in browser extensions (when distributed through the stores). Because some of them have inline javascript. In theory, it should be blocked (see https://developer.chrome.com/extensions/contentSecurityPolicy#JSExecution), but, for some reason, it works when I manually install the extension on Chromium 71. Will it still work when distributed through the Google store? I don't know.

To sum up, I would not claim about new ZIM files compatibility for now.

[Jaifroid]

Could we call it "Preliminary support for x" and add a brief explanation that users need to use the built-in search functionality?

The way I've worked around lack of JS in Kiwix JS Windows is documented in Provide a UI for accessing content of inaccessible ZIMs.

While it would be preferable to use the supplied UI, it's currently extremely challenging to do it generically, because I can't intercept JS calls to the "server" in the proprietary UIs in jQuery mode. There are some tricky patches that allow interception of XMLHttpRequest in non-SW contexts, but that's not enough, as it's not the only method the UIs use to fetch content.

The Kiwix JS Windows workaround is generic -- it's just an extension of our current search functionality. I also add an instruction when active content is first detected. It looks like below except the standard Bootstrap colour would be light blue in Kiwix JS, not purple ;-) . User can dismiss it permanently.

It would be possible to make certain bits of these UIs work non-generically, but we'd have to detect and patch the UI elements ourselves, and then keep them up to date as the ZIM UIs change. Life is short!

^^^^^^^^^^^^^^^^^^^^^^^^^^

[mossroy]

I suggest to add the "Preliminary support for x" lines in the changelog, at least.
Do you think we could use the metadata of the ZIM file to recognize these kind of ZIM files (only in jQuery mode), and display this kind of warning/explanations in this case?

[Jaifroid]

I currently test the raw html (in jQuery mode) for script blocks other than those of type text/html (these are React blocks) and math/html (these are MathJax blocks, primarily used in Stackexchange ZIMs). If there's a better test using metadata, that would be good, but otherwise that test is simple and does the job. The warning is only shown in PhET, Gutenberg, dirtybiology, TEDx, and is not triggered in Stackexchange and Wikimedia ZIMs I've tested (EDIT: I forgot, it is triggered, intentionally, in Stackexchange, because they're difficult to search as well).

Would you like me to backport just the warning at this stage? We'd have to word the warning a bit differently, because without the Archive Index UI, the spacebar in Kiwix JS currently just shows the first 50 items, but there is no way to select the next 50 other than to guess the starting letter. That's why I added an alphabet selector and Previous | Next.

[Jaifroid]

PS You can test the current Kiwix JS Windows implementation of this feature in Firefox or another browser from the github.io test environment here (only in jQuery mode, I haven't incorporated all the latest updates to SW mode yet):

https://kiwix.github.io/kiwix-js-windows/www/

(Switching ZIM files is currently a bit buggy in that interface, because UWP doesn't use that functionality and I broke something with monkey wrenching -- just search for a new page, any page, after you've loaded a different ZIM, and it should clear the remnants of the old ZIM.)

[mossroy]

The test on script blocks you describe suits different needs.
I was more thinking about :

• in jQuery mode only, read in metadata some info to recognize ZIM files that are "half-supported" like dirtybiology, ted/tedx, oer4schools. It might be based on the "Source" metadata (see https://wiki.openzim.org/wiki/Metadata)
• display a warning that it's not fully supported, and an advice on how to reach some content anyway
  But maybe it's too much work before releasing 2.5...

[Jaifroid]

I don't see metadata that would allow us to tell, generically, that a ZIM has a proprietary UI that depends on technologies we can't support. If I understand you correctly, we would have to maintain a known list of ZIM types that are problematic, and we'd need to distinguish between earlier ZIMs that didn't use a React-based UI, and those later ones that now use such a UI, so I don't think it would be straightforward. This is why, in Kiwix JS Windows, I opted to have a small test that detects the type of code that can't be run in jQuery mode and then activates a Bootstrap alert. The test can be made more or less subtle as needed.

[mossroy]

You're right. Your approach is much better.

If it's not complicated, I'd vote for a backport of the bootstrap alert, based on the detection of script tags of type different than text/html.
I think it's enough to warn the user that the ZIM file is not fully supported.
At this point, I would not backport the archive index UI.

Regarding the wording, here is a proposal :
Unable to display active content: this ZIM file is not fully supported in jQuery mode. Try to switch to ServiceWorker mode in the settings (if supported by your platform). Else some content might be available through a search (type some letters in the search zone). [Permanently hide]

[Jaifroid]

@mossroy I'll have a go at backporting just the bootstrap alert.

[mossroy]

OK now that #466 is done, I think we can follow the usual procedure for a release :

• a few tests
• update the changelog file
• move open issues to 2.6 (already done)
• create a tag on git : it should trigger the generation of unsigned extensions by Travis
• upload the unsigned extensions on Firefox and Chrome stores
• upload the application for ubuntu touch on https://open.uappexplorer.com
• prepare the source code for version 2.6
• when available, copy the signed extension binaries in https://download.kiwix.org/bin/browsers/
• communicate about these new versions

[mossroy]

I've created the tag, published on Firefox and Ubuntu Touch stores, and prepared the source for version 2.6
@kelson42 : could you please publish on Chrome store the file https://download.kiwix.org/nightly/2019-01-16/kiwix-chrome-unsigned-extension-2.5.0.zip, and then copy the Firefox and Chrome binaries in https://download.kiwix.org/bin/browsers/ ?

[mossroy]

Reminder for @kelson42 : the Google Chrome store and https://download.kiwix.org/bin/browsers/ don't have version 2.5 yet.

[kelson42]

@mossroy Yes, really sorry for this extrem delay on my side. Will try to do it this evening.

[kelson42]

@mossroy I finally have done it :)

[mossroy]

Great, thanks!