Title with question mark not handled correctly in Service Worker mode

[Jaifroid]

Using the ZIM gutenberg_it_all_2022-01.zim, if I search for the title Che cosa è l'amore? in jQuery mode, I can open the pages corresponding to the book and the cover with no problem.

If I switch to SW mode and search for the same title, either from our search field, or by searching for the author Panzoni in the custom UI and then click on the title, I get an error in console: Title A/Che cosa è l'amore not found in archive.

See screenshot, which shows first the error from the custom UI, and then the same error from our own search.

I think we should fix this before releasing 3.3.

[Jaifroid]

It should be noted that the click on the title from our own UI is failing to find the dirEntry in SW mode, even though the dirEntry has already been found in order to display the found items (and a correct direntryid has been composed). The search entry looks like this in the html:

<a href="#" direntryid="479987692|15|A|112|10|Che cosa è l'amore?.38140.html|Che cosa è l'amore?|false|undefined" class="list-group-item">Che cosa è l'amore?</a>

[Jaifroid]

I've determined that the issue is with the question mark in the title, not the quotation marks or apostrophe. The problem is that in the Service Worker we remove any potential URL parameters, like '?cgi=true'. To do that we detect a question mark or a # in the title, and assume that anything after it is a query string.

We decode the title before checking for the URI component, which clearly we shouldn't do. However, when clicking on a title from the search UI, the title is not encoded in the first place, as can clearly be seen from the HTML I quoted in a comment above. In fact, we subsequently encode it in order to set the iframe's src to it.

So there are in fact a few issues here. The way we are presenting the titles in the UI is unsafe, as they are not encoded and will fail if, for example, they have double quotation marks in them.

Then, in SW, we should test the still encoded URI, because any querystring should not in principle be encoded. However, I'm not sure it's safe to assume that, and it's going to be difficult to find a ZIM with such a querystring in order to test code. I guess all we can do is a best effort.

[mossroy]

Nice finding.
And you're certainly right about the origin (encoding issues)