Bug 138485 - help.l.o search result links to other page than where the search string was found
Summary: help.l.o search result links to other page than where the search string was f...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Documentation (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: New-Help
  Show dependency treegraph
Reported: 2020-11-25 12:55 UTC by Lionel Elie Mamane
Modified: 2021-03-20 12:46 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2020-11-25 12:55:10 UTC
When doing a search on help.libreoffice.org, clicking on a link in the search results brings one to a different help page than the one where the search string was found.

It looks like it always send to the "writer" variant of the help page, even if the writer variant is not a match for the search.

Steps to Reproduce:
1. open https://help.libreoffice.org/ in a browser
2. in the top fulltext search box (not the index search box on the left), enter "whole sheet export" WITH the quote characters.
3. click the magnifying glass icon
4. this brings one to https://help.libreoffice.org/7.0/en-GB/search?P=%22whole+sheet+export%22&DEFAULTOP=and&xP=ZBwhole%09ZFwhole%09ZSwhole%09Zwhole%09ZBsheet%09ZFsheet%09ZSsheet%09Zsheet%09ZBexport%09ZFexport%09ZSexport%09Zexport&xFILTERS=.%7E%7E
5. there is one result. Click on it.
6. This brings one to https://help.libreoffice.org/7.0/en-GB/text/shared/01/ref_pdf_export_general.html?&DbPAR=WRITER&System=UNIX
7. With one's browser built-in "search in this page" feature, search for "whole sheet export" (without the quotes)
8. Observe that the page does not contain this phrase and is thus not a match for the search requested!

Actual Results:
One gets sent to the wrong page https://help.libreoffice.org/7.0/en-GB/text/shared/01/ref_pdf_export_general.html?&DbPAR=WRITER&System=UNIX

Expected Results:
One gets sent to the correct page
which is presumably the match that was actually found by the website's search engine.

Reproducible: Always

User Profile Reset: No

Additional Info:
The difference between the two URLs is replacing &DbPAR=WRITER by &DbPAR=CALC
Comment 1 Olivier Hallot 2021-03-18 12:08:23 UTC
For information
The top search box uses omindex from the Xapian project.


Relevant part of the update script: 
omindex --follow --track-ctime \
        --spelling ${s:+--stemmer="$s"} \
        --db="$DESTDIR/${v}_${l}" \
        --url="/$v/$l/" \
Comment 2 Rafael Lima 2021-03-20 12:46:18 UTC
The problem here seems to be that ref_pdf_export_general.xhp is a shared file and it determines whether it's Calc or Writer related based on the currently selected application in the Help web page.

There's a switch statement in the file that displays this content only for Calc.

<switch select="appl"><case select="CALC">
  <h3 id="hd_id51574108224576">Whole sheet export</h3>
  <paragraph role="paragraph" id="par_id81574108602417">Export one sheet per page.</paragraph>

What seems to be happening is:
1) omindex search for the string "whole sheet export" inside all XHP files and finds it ref_pdf_export_general.xhp
2) Then it creates the link for the user to access the page, but it assigns DbPAR=WRITER to the link
3) Because of the wrong DbPar, the searched contend is not shown to the user

Maybe this happens because this is a shared file (located in text/shared/01/), the search system assigns it to be DbPar=WRITER as some sort of fallback.