Description: When opening LibreOffice with ms schema like: >"C:\Program Files (x86)\LibreOffice\program\soffice.exe" "ms-excel:ofe%7Cu%7Cc:\Sample.xlsx" it won't open, splash disappeared and nothing happened. If ms schema is not encoded, LibreOffice and xlsx document in editor opens fine: >"C:\Program Files (x86)\LibreOffice\program\soffice.exe" "ms-excel:ofe|u|c:\Sample.xlsx" This bug prevents open documents from Chrome browser as it does such schema encoding. It happens on Win 10x64 with all updates and LibreOffice 6.2.4.2 Steps to Reproduce: 1. Install all Win 10 updates. 2. Install LibreOffice 6.2.4.2 3. Run from cmd: "C:\Program Files (x86)\LibreOffice\program\soffice.exe" "ms-excel:ofe%7Cu%7Cc:\Sample.xlsx" Actual Results: LibreOffice not launch. File not open. Expected Results: LibreOffice launch and open file. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.2.4.2 Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
LibreOffice installer registers the scheme handlers in registry with UseOriginalUrlEncoding set to 1. Browsers are not expected to encode the URIs themselves in addition to existing encoding. Please file a bug against Chrome.
(In reply to Mike Kaganski from comment #1) > LibreOffice installer registers the scheme handlers in registry with > UseOriginalUrlEncoding set to 1. Browsers are not expected to encode the > URIs themselves in addition to existing encoding. Please file a bug against > Chrome. Shouldn't the LibreOffice die quietly in this case?
(In reply to uachatse from comment #2) > Shouldn't the LibreOffice die quietly in this case? It doesn't "die" or "crash"; it simply ignores invalid path (as opposed to a valid, but non-existing path). You may check that by pre-launching LibreOffice, and check if it will "die" when executing your command; compare that to any real crasher (e.g., from bug 119039) - which would make the pre-opened LO disappear, and compare to commands like > "C:\Program Files\LibreOffice\program\soffice.exe" "c:\Sample.xlsx" where file name is valid but doesn't exist, and this produces an error message; and with > "C:\Program Files\LibreOffice\program\soffice.exe" "c:\Sam:ple.xlsx" where a colon ":" in the middle of the path makes path invalid, and LO ignores it quietly. If you like, you may file an enhancement to also report error when opening invalid paths, but please do so in a different report, since it's easier to trach problems when they are filed for valid reason from the start. Thanks!