Handle local photo storage separately

[tomsaleeba]

Currently we save a single record in IndexedDB that contains everything for an observation including photos. The IndexedDB best practices advise against doing that:

While IndexedDB makes is possible to store large, nested objects as a single record (and doing so is admittedly quite convenient from a developer perspective), this practice should be avoided. The reason is because when IndexedDB stores an object, it must first create a structured clone of that object, and the structured cloning process happens on the main thread. The larger the object, the longer the blocking time will be.

This means we need make the following changes:

• create a separate IndexedDB just for images
• on save of an observation, save each image as its own record with some unique ID
• save the obs record with the IDs to the full images and extract the EXIF thumbnail from each photo (it's each to do) and save that thumbnail in with the obs record.
• change the processing pipeline to read the full image from storage
• change the edit/delete of obs to delete orphaned photos
• possibly change the obsDetail page to read the full size photo from storage, but probably not as it won't perform.
• for all of this, try to push as much as possible off the main thread and into a worker
• consider if we can wrap the save of an obs record and its photos in a single transaction

[tomsaleeba]

When it comes to dealing with photos that don't have a thumbnail as part of the EXIF, we have some options:

• use the full size photo. Not great because we're back in the same spot as before this change
• use no photo. Not so bad if it's not the first photo (or we have at least one photo with a thumbnail), but if one is missing a thumbnail, then they probably all are.
• create our own thumbnail. We sort of touched on this before with the whole resizing/compression thing and that wasn't very performant.

The third option is the best for UX. We need to benchmark some options and see how they perform. The options are:

• Jimp.resize. Doesn't seem to use a canvas, it manipulates the bytes.
• browser-image-compression. We used this before but it didn't seem to want to run on a worker thread. More relevant now, we need to launch it from a worker. It probably doesn't matter if it runs in a separate worker. Uses canvas.
• image-blob-reduce. Uses canvas.
• jqthumb. Uses jquery and looks orphaned.
• JIC. Uses canvas.
• compress.js. Uses canvas.

Any solution that relies on using a canvas to do the resize might not be suitable. I don't think workers can use a canvas. They might be able to use an OffscreenCanvas but it's still experimental and Safari doesn't support it.

On the observation details page, I'm not sure if we can get away with showing the thumbnail or if we want the full size image to render. Perhaps we can have a lazy-load approach where we show the thumbnail and a button that will load the full-size photo. That way, we're less likely to be loading photos and if doing so causes issues, the user can just not do that.

[tomsaleeba]

Some thoughts on migrating. We need to move all the existing photos out into their own records, but if the user's phone is already full, we have to be able to read/write records without killing the browser tab.

If we no longer load photos, we'd be fine. But with the expectation that all photos are thumbnails, we plan on blindly loading them safely. Perhaps we should add a sanity check during obs record load to protect against:

1. pre-migrated environments so we don't load all photos into memory
2. larger than expected thumbnails

According to page 27 (of the PDF, page 21 in the document) of the spec, the thumbnail will be less than 64kb:

...but maybe it's best to verify.

Back onto the topic, if we run the migration before we let anything else load, we might be safe with memory usage.

As for how to tell if we need to do a migration, perhaps we should adopt the approach like other DB migration software. Have a list of migrations and set flags when they've been applied.

[tomsaleeba]

Doing the migration on 20 test observations (generated from the admin screen) takes:

• 30 seconds on my desktop
• 140 seconds on my LG V30, while creating another observation (and the UI was still usable)

[tomsaleeba]

We're experiencing https://github.com/localForage/localForage/issues/910 in Safari.

Test process:

1. go to <wow-instance>/settings, e.g. https://dev.app.wildorchidwatch.org/settings (you don't need to login)
2. set "when to sync" to "never"
3. open the admin page by using 7 taps on the version in the menu easter-egg or go to /zzadmin
4. if you can't scroll, tap the title of the "login" toast message 7 times to hide it for a minute
5. scroll down to the GH-69 test card
6. open the browser devtools console, make sure you can see debug level messages
7. click the button to create 20 observations (this has worked all but one time for me)
8. when the observations are created, refresh the page
9. you'll see the migration start to run
10. if the error is going to happen, it's as the first record is written back to the DB

Error screenshot:

Test results:

• Safari 13.1.2 desktop 13.1.2 desktop: error seems to happen consistently when trying to migrate. Have also seen it when trying to create the first record of the test case too
• (same machine as above) but in private mode: worked two times in a row in one session and again in a fresh session
• iOS 13.6 iPhone 11 Pro Max Simulator (on LambdaTest), Version 11.7 (921.9.1), SimulatorKit 581.9.1, CoreSimulator 704.12.2, macOS 10.15.4: fails consistently. Tried a few times over a few different sessions that started clean (as clean as you can hope for on LambdaTest)
• (same as above) but in private mode: works (only one try)
• Safari 14.0 desktop (on LambdaTest): works, two tries in one session
• (same as above) but in private mode: works, one try
• Safari 13.1.1 desktop (on LambdaTest): works, two tries in one session
• (same as above) but in private mode: works, one try

[tomsaleeba]

Also seen this error on LambdaTest iOS 13.3 (Safari 13.1) simulator:

This is just after the page refresh when the migration starts to run.

[tomsaleeba]

When I change the code for https://github.com/localForage/localForage/blob/c1cc34f/dist/localforage.js#L1060 to:

                    transaction.onabort = function () {
                      console.warn('abort')
                        reject(req.transaction.error);
                    };
                    transaction.onerror = function () {
                      console.warn('error')
                      try {
                        var err = req.error ? req.error : req.transaction.error;
                        reject(err);
                      } catch (err2) {
                        reject(err2);
                      }
                    };

...so we stop masking the true error, we get:

Apparently this error can be triggered by:

new WeakSet().add(1);

When looking in the built code for our obs worker, the only mentions of a WeakSet I can find come from:

./node_modules/@sentry/utils/esm/memo.js
./node_modules/lodash/lodash.js

Lodash doesn't seem to use WeakSets internally.

I can't find any use of WeakSet in our main code:

yarn serve:debug
curl http://localhost:8081/js/app.js | grep -i weakset
curl http://localhost:8081/js/vendors.js | grep -i weakset