If I start a new document or spreadsheet, then attempt to open an existing document before saving the untitled new document, LO makes the untitled document and window disappear and leaves me with only the second document I opened. Expected behavior: I should be able to start a new document from a template, with or without editing or saving the new document, then be able to open any subsequent document that already exists and still have BOTH documents open for editing. I have not tested this with Impress, Base, Draw or Formula. This bug occurs regardless of if I start the first untitled new document from scratch or a template. (I just happen to use a particular template often in combination with opening an existing spreadsheet that I need to copy sheets from the existing to the template for) Workaround: Save As the untitled document before opening the second existing document. Problem with workaround: in the case of using a spreadsheet template to conduct calculations that are never to be saved, opening another document makes this "calculator spreadsheet" disappear.
Hi Earis, Thanks for your report. In my opinion this is by design. It has been like that at least since 2004 I think. Solution for me is simple: type a space in the new document. I would suggest to close this as not being a bug... what do you / others think? Cheers - Cor
Thanks Cor, I see that workaround is better than my original. Another I guess would be to change the order of opening the documents. I don't see why this would happen by design as it doesn't seem very intuitive to me. If I bother to create a new document/spreadsheet, especially from a saved template, I have a reason for needing it open. It shouldn't disappear simply because I open another existing file in LO before I begin editing that new blank file. (I usually even NEED something from that existing file to begin that editing) Perhaps the LO/OOo team thinks this only occurs when someone mistakenly starts a new blank document/spreadsheet, but I can assure them, not only is this not the case, I can think of plenty of reasons why this workflow would be used. Anyhow, it isn't critical, and there are easy to implement workarounds be they annoying to have to use on a daily basis. I'd ask it remain open to see if anyone else desires a fix, but if it ends up as wontfix I won't cry over it.
I am concerning by this weird behavior too. For me it's not the expected behavior. So set status to NEW. Best regards. JBF
Just for information, the steps to reproduce: 1. New Writer; 2. File - Open - (an existing text document). The expected behabiour is the "untitled" file created in step 1 does not close when you do step 2.
Not a bug in any way.
Katarina Behrens committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/acd820fd39394acc9829836a597c277d8965242e%5E%21 tdf#83722: don't recycle frame with unmodified template It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #6) > Katarina Behrens committed a patch related to this issue. > It has been pushed to "master": Flowers to you :)
Katarina Behrens committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/12679b370f7ec0a73c4c10c7de5c255a7d2cfca0%5E%21 tdf#83722: Restrict the condition only to File > New It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #8) > Katarina Behrens committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/+/ > 12679b370f7ec0a73c4c10c7de5c255a7d2cfca0%5E%21 > > tdf#83722: Restrict the condition only to File > New Are you sure that that is a good idea ? Indeed if the new empty file is opened by using a button in the sidebar of the startcenter, the old behavior is still there. Best regards. JBF
> Are you sure that that is a good idea ? Indeed if the new empty file is > opened by using a button in the sidebar of the startcenter, the old behavior > is still there. It was never my intention to implement opening new document in a new frame at ALL TIMES but only in the following two use-cases i) user has opened a template, they didn't modify the template (so the document is still 'Untitled X') but they don't want to have the content provided by the template overwritten by a new document ii) user has opened a new document via File > New (or the same in toolbar), they haven't started typing yet but explicitness of this action implies they don't want to lose this blank document to a new file either Everything else -- blank document from start centre, starting swriter/scalc/sdraw.exe with no initial document etc. -- contains no such explicit action or intent ("this is my template, my new file, please don't touch it") and nothing has changed there, such frame used to be, is, and will be in the future overwritten by a new document So ye, I'm positive this is if not completely good then at least acceptable idea. If you people disagree please open a new ticket
(In reply to Katarina Behrens (CIB) from comment #10) > So ye, I'm positive this is if not completely good then at least acceptable > idea. If you people disagree please open a new ticket I like the improvement. Thanks Bubli. Verified in Version: 6.3.0.0.alpha1+ Build ID: b26b6cab5d8147d35f76a21c333719c80840d08d CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-20_23:15:15 Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US Calc: threaded
Please see https://bugs.documentfoundation.org/show_bug.cgi?id=126700. This patch causes a significant nuisance for me and is not working according to the use cases outlined by the author of the patch.