Description: Unable to view/access local Help in Writer; after uninstalling the help files I could access online help; re-installing the local help files reproduced the problem. [Very Frustrating...] [My Browser & all my apps were working normally] Steps to Reproduce: 1. Make LibreOffice the default app to open .html files 2. Open Writer 3. Open Help Actual Results: Unable to view/access local Help in Writer [The first click opened the blank NewHelp0.html Writer/Web file (and disabled the rest of the Help menu...)] subsequent clicks opened NewHelp1.html etc. Expected Results: A) Using the help package's Repair (or uninstall followed by re-install) SHOULD have fixed the problem (to allow access to the normal help files) B) A warning message "LibreOffice must NOT be the default app to open .html files -- fix in Settings ¦ Default Apps" would have helped. Reproducible: Always User Profile Reset: No Additional Info: I don't know how LO became the default app. My browser was working as normal. Version: 25.8.4.2 (X86_64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-ZA (en_ZA); UI: en-ZA Calc: CL threaded
Can not reproduce. Win11 25H2 (26200.7623) The off-line Help installed with the en-US LibreOffice_25.8.4.2_Win_x86-64_helppack_en-US.msi from the archive and HASH sums checked valid. MS Edge version 143.0.3650.139 selected in os as the browser to open the HTML help files. No issue with any <F1> selection on any UI element or field, get a clean timely opening of the appropriate Help article. Version: 25.8.4.2 (X86_64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #1) > Can not reproduce. Win11 25H2 (26200.7623) > > The off-line Help installed with the en-US > LibreOffice_25.8.4.2_Win_x86-64_helppack_en-US.msi from the archive and HASH > sums checked valid. > > MS Edge version 143.0.3650.139 selected in os as the browser to open the > HTML help files. > > No issue with any <F1> selection on any UI element or field, get a clean > timely opening of the appropriate Help article. > > Version: 25.8.4.2 (X86_64) > Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df > CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: > Skia/Vulkan; VCL: win > Locale: en-US (en_US); UI: en-US > Calc: CL threaded Did V Stuart Foote read my full report (not just the headline)? Did he set the default HTML reader to LO ? The fault only occurs THEN: and it can only be fixed by changing this. LO does not detect the fault.
Did V Stuart Foote read my full report (not just the headline)? Did he set the default HTML reader to LO ? The fault only occurs THEN: and it can only be fixed by changing this. LO does not detect the fault.
Guess we assumed no one would be inclined to set LibreOffice to be their default app/program to handle .HTML and especially the Help documentation. The response to that invalid user action, of attempting to open URI with Writer/Web, is actually correct behavior. Otherwise an issue is confirmed, that when I incorrectly set Writer to be the default to open an .HTML format the <F1> linked help file is opened into Writer Web as 'No script' with other *ugly* impacts rendering the LO UI and progressing blank documents generated named "New Help[0-9].html" Clearly a nonsensical user action, but since it is possible I guess we should at least warn against it.
(In reply to V Stuart Foote from comment #4) > I guess we should at least warn against it. How? My take: I would rather drop HTML support than putting effort in. There are better suited tools and we do not need to be the Swiss army knife.
(In reply to Heiko Tietze from comment #5) > (In reply to V Stuart Foote from comment #4) > > I guess we should at least warn against it. > How? The Yellow alert bar, or a popup when Writer/Web module doc handler is launched--detection is via TypeDetection Service, right? But especially do so if we can detect that os/DE defaults have incorrectly set LibreOffice or Writer, Writer/Web for the file type (MIME or XSD). > > My take: I would rather drop HTML support than putting effort in. There are > better suited tools and we do not need to be the Swiss army knife. +1, and my continued agreement to strip out Writer/Web handling from me. That would resolve the issue--LibreOffice would no longer try to parse modern HTML5/XHTML with broken HTML4 Transitional. https://bugs.documentfoundation.org/show_bug.cgi?id=95861#c3 https://wiki.documentfoundation.org/Proposals_for_removing_features#Writer/Web Though the HTML5/CSS3 import/export filters still need improvement for round tripping of modern web content. We just drop the HTML/CSS direct markup editing mode.
(In reply to V Stuart Foote from comment #6) > The Yellow alert bar, or a popup when Writer/Web module doc handler is > launched--detection is via TypeDetection Service, right? This means to always alert people not only if the help is weirdly loaded into the application.