Notesnook v3.0.5 fixes 10+ bugs via 37 commits. Improved conflict handling during sync, fixed web app on Safari, added support for duplicating locked notes, brought back Ctrl + F to search all notes, and fixed search/replace in editor.
Previous releases:
v3.0.4fixes a critical bug with 2FA emails/SMS not getting sent during login. Everything else is the same as v3.0.3.v3.0.3fixes 15+ bugs via 40 commits. Replaced force sync with separate force push & force pull buttons, added various fixes to real-time sync, improved editor reliability on mobile & fixed export of locked notes.v3.0.2fixes 10+ bugs via 24 commits. Attachment manager for logged out users, much improved attachment handling fixing a couple of critical issues, pre-v3 backups no longer throw errors, and many other fixes.v3.0.1fixes 20+ bugs via 65+ commits. This release adds SQL based search, improves editor performance & add support for multiline search replace in editor.
Improved conflict handling during sync
Ever since releasing v3, sync related issues have almost been reduced to 0 (emphasis on almost). While we fixed "my notes aren't syncing", we now have a new issue: "my note got reverted to an older version". I don't know which is worse but in this release, we tracked down and fixed this issue as well.
Here's a scenario:
- You are editing a note while offline on your laptop.
- A few hours later, you open and edit the same note on your mobile (which is online and syncs the changes immediately).
- Next morning, you open your laptop, sync runs, but you don't see the changes you made on the mobile. You open your mobile app and see that the note has reverted all your changes.
At this point, you either delete the app or, if you are handy with a phone, you restore your changes from the note history. The question remains though, why did this happen? Shouldn't newer changes almost always take priority over older changes in sync?
Turns out we were bumping the dateModified property on each item after pushing it to the server. If you remember from my previous posts on how the sync works, we always set the synced property to true after syncing each item. What happened was, we were also bumping the dateModified property along with changing the synced property.
How does the app know which item is newer? By using dateModified. So imagine that you edited something at 5 PM but synced it at 10 PM. What would be the value of dateModified? 10 PM. And that is the bug.
The fix was simple. We make sure that nothing touches the dateModified property. However, that still doesn't fix the problem.
Even if the above issue never occurs, you'll notice how your unsynced changes from the laptop would get replaced by the newer changes made on your mobile device. Is that really the intended behavior? What if you noted down something really important?
To handle this unique situation, Notesnook will now trigger a conflict if the version of the item you have on your device isn't synced. It won't care if it is older or newer. If it is unsynced that means there is important information and you should have the choice of how to preserve the information.
Fixed note duplication (including support for duplicating locked notes)
v3 broke note duplication almost completely. While we were duplicating the title & content of the note, everything else, like the notebook, tag or color, was completely ignored. This is now fixed.
Another unintentional limitation was that we didn't allow duplicating locked notes (for some reason). That made no sense, though, so it has been removed.
Bring back Ctrl + f to search all notes
I didn't even know this was broken until I tried to search in a readonly editor and noticed the notes list flickering like a light bulb. Turns out it was trying to navigate to /notes/search which no longer exists. We now handle all searching within the same route. This is now fixed and pressing Ctrl + f anywhere outside the editor will open notes search.
Fixed web app not working reliably on Safari
Safari has some really frustrating problems when using Workers. It doesn't auto close a worker when you navigate or refresh the page, it also doesn't free any WebLocks automatically. This results in the app getting badly stuck on load, and the only way to work around it is to close the tab and open the app in another tab. Not really convenient.
This has now been fixed. Notesnook now works on Safari just like on other browsers.
Fixed password/pin based app lock on Android
This issue took us multiple days to figure out. And the fix?
We were using the wrong size salt: 12 bytes instead of 16 bytes. Turns out that triggers undefined behavior instead of throwing an error. Fixing this was as easy as replacing the old salt with new one.
What about people who already have app lock enabled? Well, we have added an option to remove the app lock using your account password. If that doesn't work, you can always just reinstall the app (not as convenient but no other way, unfortunately).
Fixed pricing plans stuck on loading on Android/iOS
This issue wasn't highlighted a lot even though it has been occurring for quite some time. Notesnook uses regional pricing which requires getting the appropriate SKU/ProductID depending on where you are located. This is handled by a Cloudflare Worker.
When we were migrating the Notesnook Core to TypeScript, I had changed the signature for the class responsible for communicating with the Cloudflare Worker. Unfortunately, I forgot to make the appropriate changes in the mobile app resulting in the app always getting stuck when getting the pricing information.
This has now been fixed, and you'll be able to purchase a new subscription from Android/iOS just like before.
Taking screenshots with app lock turned on
Normally when you turn on the app lock, the app automatically disables screenshot taking. This is the default behaviour. However, sometimes you might want to take screenshots without disabling the app lock.
In this release, you can disable Privacy Mode from Settings (on by default when you enable app lock) to take your screenshots.
