Start Impress with a new presentation without using a template. Add a shape to the master, add a shape to the slide. Save the document by clicking on "save" button. The "file save as" dialog opens. Enter a file name and save. Observed behavior: The dialog closes and opens immediately again. The document is not saved. This behavior repeats when click on "save". The effect is, that it is not possible to save a newly created document. Simple save of on already existing document works, but "save as" does not work for existing document too. I see the error in Version: 6.3.0.0.alpha0+ (x64) Build ID: c03a70770e667290e3766e639300c7ecef5eea1f CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2018-11-20_15:40:52 Locale: de-DE (en_US); UI-Language: en-US Calc: threaded It was OK in Version: 6.3.0.0.alpha0+ (x64) Build ID: d71ea82055a6a304493c7eaa90809a348e23784d CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-19_04:56:18 Locale: de-DE (en_US); UI-Language: en-US Calc: threaded
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-2&id=02a5cbb9814dc224114dfbf3bc0b6c53658450c9 author Ilhan Yesil <ilhanyesil@gmx.de> 2018-11-19 14:50:25 +0100 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2018-11-20 22:43:46 +0100 commit 02a5cbb9814dc224114dfbf3bc0b6c53658450c9 (patch) tree 493bc99f007688d7580ccd074b067a281f08d9a3 parent 8848881e25e75387a7ac26503c7da3787dd25b80 (diff) tdf#121497 "Save As": File Format Type unchanged in Windows Bisected with: bibisect-win32-6.2 Adding Cc: to Ilhan Yesil Note: No need to add any shape or create any master page. it fails with a blank document as well...
Not just Impress, all modules. Critical.
I'm in favor of just reverting everything in Bug 119747 and Bug 121497. I agree with https://bugs.documentfoundation.org/show_bug.cgi?id=119747#c2: "On most platform the filter itself is hidden, so a user just sees the "(.odt)"."
(In reply to Timur from comment #3) > I'm in favor of just reverting everything in Bug 119747 and Bug 121497. > I agree with https://bugs.documentfoundation.org/show_bug.cgi?id=119747#c2: > "On most platform the filter itself is hidden, so a user just sees the > "(.odt)"." Ilhan is still working on it -> https://gerrit.libreoffice.org/#/c/63715/
*** Bug 121645 has been marked as a duplicate of this bug. ***
*** Bug 121694 has been marked as a duplicate of this bug. ***
Perhaps it might be worth considering reverting this for now, and resubmitting together with the fix.
While this is sorted, an Expert Configuration toggle of "UseSystemFileDialog" false will bypass the broken win32/VistaFilePicker code and allow folks to work with Windows builds.
(In reply to Xisco Faulí from comment #4) > (In reply to Timur from comment #3) > > I'm in favor of just reverting everything in Bug 119747 and Bug 121497. > > I agree with https://bugs.documentfoundation.org/show_bug.cgi?id=119747#c2: > > "On most platform the filter itself is hidden, so a user just sees the > > "(.odt)"." > > Ilhan is still working on it -> https://gerrit.libreoffice.org/#/c/63715/ This is not an issue that should be worked on and left. I think that all should be reverted, because of the quoted reason.
*If* the change introduced in bug 119747 is to be kept, then the change author must introduce a map between unmodified filter names and the changed versions, ensure that the modified versions are unique, and make sure to return unmodified strings when selected filter is queried. Otherwise, I support just reverting it all, because perceived benefit is negligible compared to regressions right and left.
Sorry that I caused this inconvenience. I'm working currently on a solution in consultation with Thorsten Behrens.
*** Bug 121771 has been marked as a duplicate of this bug. ***
We have 3 bugs and 3 duplicates. Who can make a decision on whether to proceed or revert, considering the value of first change? Xisco, please comment or propose for ESC.
Don't think we need the ESC decision at this point. We have some time before 6.2 still; and even when time approaches, we can simply revert for 6-2 branch. When the problem is being worked on, why force some extraordinary decisions?
(In reply to Mike Kaganski from comment #14) > Don't think we need the ESC decision at this point. We have some time before > 6.2 still; and even when time approaches, we can simply revert for 6-2 > branch. When the problem is being worked on, why force some extraordinary > decisions? Yes, I agree with you. Give some time to Ilhan Yesil to work on it and fix it. We can always revert it later on if it's still problematic
Fixed with commits https://git.libreoffice.org/core/+/1d427cd700704bc80378e250d3350b505e4413bd https://git.libreoffice.org/core/+/38a47bc3a4f618da4613968d28c08c8dda064cea https://git.libreoffice.org/core/+/f553e34aff94fd9bce9cce77e0a723021be7c38a
Test was OK (Writer + Calc) with Version: 6.3.0.0.alpha0+ (x64) Build ID: beae6c7a7f163daad0d4dea63a3d403af2745fd1 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-12-07_01:25:50 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded Tested: - Save as - Save a Copy - Export as PDF (Result: PDF documenst readable by Acrobat Reader, file size and quality of embedded pictures varies depending on export options)
*** Bug 121782 has been marked as a duplicate of this bug. ***
*** Bug 121990 has been marked as a duplicate of this bug. ***
All tests described in Comment_17 repeated with Version: 6.2.0.0.beta1+ (x64) Build ID: 030c9f1fcb8fecfd8b80d9f7f73025bab8a1b65b CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:libreoffice-6-2, Time: 2018-12-11_08:04:39 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded All results were OK as in the tests before with LODev 6.3 alpha0+!