Under certain conditions the OPACBrowseResults (navigation between results in OPAC) feature will have a broken link "back to results". To test: - Search for a term with diacritics. You can cheat a little here and search for something like "bööks" with the sample data. (ö will also find o). It's important that it's at least to result pages. - Go to the last result of the first result page - Verify the URL "back to results" works and diacritic shows up nicely - Go to the last result of the first page again - Navigate "Next >>" - Check "Back to results" again - Verify the link is broken and the diacritics are mangled Link looks something like this: http://localhost:8080/cgi-bin/koha/opac-search.pl?offset=20&q=b%C3%83%C2%83%C3%82%C2%B6%C3%83%C2%83%C3%82%C2%B6ks
Still valid for 18.11.
Created attachment 115529 [details] [review] Bug 22070: Try to fix encoding and escaping issue on browse result Pretty sure this does not work but in my tests it seems to fix the problem. Note that if there are several pages, the next link won't appear if you are on the last result of the first page. I don't understand why this code is so complicated, couldn't we port what we have on the staff interface (browser.js)?
Could this be somehow related to the discussion on bug 20529?
The encoding issue is still present in 20.11 and master.
The Next link is not always hidden on the last result of the page, but sometimes, this might be another bug. If you keep previous/next'ing you will eventually see the next link to jump to first result of the second page and the link back to results breaks. The patch doesn't fix it.
I don't understand, Katrin. What you are describing does not seem related to this patch.
Hi Jonathan, it is related. In my test plan, it asks you to click on next from the last result of the first page, but you noted: > Note that if there are several pages, the next link won't appear if you > are on the last result of the first page. And it's true... but then it's not. I managed to sometimes have that 'next' button and then when you click it, it causes the encoding issue on the 'back to results' link.
I don't seem to be able to reproduce this bug in master
I'll have another go at making this reproducable in a simpler way: 1) Fresh ktd sample database, reset_all, even used a private window. 2) OPAC: search for: bööks 3) Open detail page of last result on the result list. 4) In the browser, click on "Previous" 5) Check the URL for "back to results" - it will show broken characters 6) Click on it - it's broken ... and the patch fixes this for me.
Created attachment 136550 [details] [review] Bug 22070: Try to fix encoding and escaping issue on browse result Pretty sure this does not work but in my tests it seems to fix the problem. Note that if there are several pages, the next link won't appear if you are on the last result of the first page. I don't understand why this code is so complicated, couldn't we port what we have on the staff interface (browser.js)? Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
I know the patch and commit message need some more work, but maybe the updated test plan in comment#9 and the SO will help to get some more eyes on it.
I do reproduce. Searching for bööks. Browsing from result n°18 to n°19 then n°20 does not break encoding. Browsing from result n°20 to n°19 breaks encoding. Browsing from result n°19 to n°18 does not break encoding. o_O
(In reply to Fridolin Somers from comment #12) > I do reproduce. > > Searching for bööks. > > Browsing from result n°18 to n°19 then n°20 does not break encoding. > Browsing from result n°20 to n°19 breaks encoding. > Browsing from result n°19 to n°18 does not break encoding. > > o_O Thx Frido, I have a feeling it could have to do with the "last record on a page" somehow?
(In reply to Fridolin Somers from comment #12) > I do reproduce. > > Searching for bööks. > > Browsing from result n°18 to n°19 then n°20 does not break encoding. > Browsing from result n°20 to n°19 breaks encoding. > Browsing from result n°19 to n°18 does not break encoding. > > o_O With or without the patch?
(In reply to Jonathan Druart from comment #14) > (In reply to Fridolin Somers from comment #12) > > I do reproduce. > > > > Searching for bööks. > > > > Browsing from result n°18 to n°19 then n°20 does not break encoding. > > Browsing from result n°20 to n°19 breaks encoding. > > Browsing from result n°19 to n°18 does not break encoding. > > > > o_O > > With or without the patch? Without patch. Feels strange to remove URI escape, we should try with URI chars like & ? =
QA: Looking here
This is very weird code. Apart from the encoding, the paging seems to be buggy too. Can reproduce the issue Frido mentioned: Back to results (pos 9 with 5 results per page WHEN coming back from pos 10) /cgi-bin/koha/opac-search.pl?idx=kw&sort_by=relevance_dsc&q=b%C3%83%C2%B6%C3%83%C2%B6k => böök The previous and next links are good, but the Back to results becomes even more bad when paging back and forth..
Have to conclude that this is not ready for passing QA yet. Just removing the encoding/escaping does not look good. We meet the issue here too of the encoding of CGI::Session. If we store unicode stuff (in the URL) within param busc, how does it get stored and how should we retrieve? It feels like we should do conversion as early as we retrieve and as late as we store it again. And such that it survives pure ASCII, Latin and 'real' Unicode. - use URI::Escape qw( uri_escape_utf8 uri_unescape ); + use C4::Search; This does not look good either. Probably we need to move URI::Escape to the top. The whole logic for Back and Next in this feature looks buggy. But that is outside the scope of this report.
I won't have time to dedicate to this in the near future.
Retested in 23.05. Accented characters create issues with the Next scroll button (become grayed out) at the end of the first page of results and breaking the Return to results button. This behavior is not present if we replace the accented characters with a regular character (é by e). The two buttons (Next and Return to results) work normally.