Since this seems to be a newer thing than 20 years ago.
Anyway, I’m the author of this post:
which is relatively popular. And for that I created a bunch of tables. The problem is the latest version of Scrivener has a bug in tables which is better demonstrated in how it stores it in snapshots:
On the LEFT is how it’s supposed to store it. And is pretty much how I have it stored in templates. On the RIGHT, you can see it stores it in Snapshots incorrectly.
Thus if the computer crashes, which it does from time to time, it relies on the snapshot on the RIGHT and then the whole table settings are messed up. This is then hours of work to fix.
I can half fix it by putting a space in the empty cells, but then that is a pain because you have to remember to delete the space every time one uses the template. I’d rather the bug be fixed. Something like empty cells does not mean null in snapshot mode.
If every single last template I made with tables (which is a lot) is broken every time I create a file from that template, it’s not fun to use anymore.
Can you please fix it? It might be low priority, but it’s high on the annoyance scale for me. Almost all of the templates I make rely and store as a table (It’s because the left item is bold, but Scrivener won’t remember after creating a file from a template on the right is not bold). I save to snapshots as a “proof of copyright” type of deal.
This wasn’t an issue in previous versions, because I spent a long time doing extensive testing on the templates before releasing them. So I think it’s a newer bug.
Definitely not anything from 20 years ago (though I think it is very safe to say that there are +20 year old bugs in tables that are all on Apple’s side!). What you are describing here is a newer problem that has cropped up in the most recent updates—I have merged your report with the main bug thread on it.
It appears that something relates either to the macOS 26 release, or perhaps fixes we applied to the software in reaction to the great swell of bugs that updated foisted upon us.
Sadly to date we have no clear reproduction on it. It seems to impact particular projects repeatedly, but once the conditions are attempted in a test project, they either don’t show up for us, or not even for the person trying to make a sample project.
As this is happening in your template, in projects created straight out of it with no modification, it might very well be something we can see as well then. I tried to access the template, but it seems Tumblr doesn’t allow one to scroll without making an account (?!), so maybe if you could send it as an attachment in a PM to me, I would be grateful!
Don’t worry about the missing icons when you open it since that’s not what you’re trying to reproduce.
Replication off of the template I made on Mac:
Open template and load it.
Make a new project off of the project
Save the file
Create a New character profile from template
Create a snapshot of the character profile. It should show up wonky on the side.
“simulate a crash” (i.e. force your computer or machine to turn off suddenly.)
And when you come back the profiles should look wonky like in the snapshot.
My computer recently crashed and the profiles were fine until it crashed for the project folders that were open, and then the bug came back. I did spot the bug before, but as I could not figure out the source I did not report it. It might be the way the tables are being stored that’s at issue. That’s my best guess. I saw a version of the bug in the beginning of January-ish, I don’t know if that helps at all.
My old UX habits, but the bug is pretty reliable from there. Might be also because I shored up the margins, but I don’t think so. It looks more like it’s forgetting where the cell dividers are ( like in HTML the td /td markers) and thus combining cells together.
I don’t know if that will help you resolve it, and sorry if this is overkill. Again, UX habits of how to describe bugs. Intermittent bugs are the worst to describe.
Excellent. Okay, while I unfortunately could not reproduce the problem of it happening in the main editor (I didn’t try a cold power-off of the system, but did force quit Scrivener which should be sufficient to simulate a crash), the good news is that taking a snapshot very much does break the table immediately, and consistently, and that’s probably good enough for us to debug against.
We have indeed tried using snapshots before, but this is the first I have seen where it happens so consistently.
I’ll get this added to the investigation. Many thanks!
