Created attachment 165114 [details] The file that I was working with when this happened the first time ● Open LibreOffice Calc. ● Either right click a cell and click ”Format Cells…” or right click a cell style and click ”Modify…”. ● Click the ”Numbers” tab. Libre office 7.0 crashes. The main window is closed, the cell style window remains visible but unusable and a ”Libre Office 7.0 Document Recovery” shows up, sometimes it's usable and sometimes it's transparent and can only be closed with the operating system's task manager (or a terminal, of course). I have tried to restart my operating system and I also reset my user profile, and the last approach actually seemed to work, but only until I opened a certain file (the one that I was working with when I noticed this the first time, and which I will attach to this bug report). So what's special about that file? Well, I happened to work with it when my operating system was shut down by a script of mine (I knew it was going to happen since I was the one starting that script in the first place, but I thought I would be able to finish my work before the shutdown, but that's another story). So today when opening that file again, LibreOffice wanted to recover it and I let it do that. The file was empty, so I just started to work at it from scratch. No big deal I thought, since I remember all of its contents anyway. Then, when I was trying to edit and add styles, this happened and it seems to happen only when I enter the Numbers tab (I didn't try all tabs, but at least I tried a few of them), with a slight delay. The same version of LibreOffice was used from the very creation of that file, so it's not an issue about incompatibility between different versions, I guess. Anyway, given the above, maybe it's not an issue about styles, but rather about LibreOffice's ability to restore files properly, I don't know. That's why I include the file, so someone can have a look and see if it's abnormal in any way. I don't know if this is operating system dependent, but I run Manjaro Linux 20.1 and LibreOffice was installed from Arch's official repositories using Pamac.
I can't reproduce it in Version: 7.1.0.0.alpha0+ Build ID: 6b2eff7d69c6e14d89dd33eaa58c01d82c541266 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Could you please paste the info from Help - about LibreOffice ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information has been provided
I ended up installing the Still version instead (just to be able to do my everyday stuff), and when doing that, LibreOffice 7 was uninstalled. But since you're asking, I reinstalled it now, and here's the info I get when I click the Version Information button in that About dialogue (in Swedish, or maybe ”Swenglish”, even if the text I get when hovering over the button says ”Copy all version information in English”): Version: 7.0.0.3 Build ID: 7.0.0-1 CPU-trådar: 12; Operativsystem: Linux 5.4; UI-rendering: standard; VCL: gtk3 Locale: sv-SE (sv_SE.utf8); UI: sv-SE Calc: threaded Here's a translation table, just in case: CPU-trådar=CPU threads Operativsystem=operating system standard=standard, default Anyway, since I didn't have it installed for a couple of days, I'm not 100 % the version I installed a few minutes ago is exactly the same as the one I installed a couple of days ago, because for some reason I can't reproduce the problem now. I guess I'll keep LibreOffice Fresh for a while to see if it comes back, then. It's very strange. Just a couple of days ago I couldn't work with it at all, it was totally hopeless, and today it works perfectly… Maybe the problem only occured in the Arch rendition and if so, maybe they fixed it since the last couple of days, I don't know.
[Automated Action] NeedInfo-To-Unconfirmed
I think we can close it, see comment 2
Actually I have had the problem once with the same (or slightly newer) version, but I haven't had time to investigate it further. If I find a way to make the bug occur almost every time, can this bug report be re-opened or should I file a new bug report?
(In reply to Johnny Rosenberg from comment #5) > Actually I have had the problem once with the same (or slightly newer) > version, but I haven't had time to investigate it further. If I find a way > to make the bug occur almost every time, can this bug report be re-opened or > should I file a new bug report? You can set it again to status Unconfirmed. Thanks