1801151 - Enhance marionette testing for IDB in Private Browsing

Status: NEW

(Core :: Storage: IndexedDB, task)

Description

[Harveer Singh]

There were couple of marionette tests which were created as part of https://phabricator.services.mozilla.com/D158597 and as per our discussion in "Testing Strategy for IndexedDB in PBM" https://docs.google.com/document/d/1R7HqY67kcRbYWg2UPeW0Oii4NC5VEojaD9X5c-X8Qi8/, It would be better to expand this testing to include more tests for below scenarios

1. In our current testing, we ensure that encryption has happened on the disk storage by verifying on disk data doesn't contain the original raw key/value anymore. It's possible that data has been encrypted or compressed by snappy. So it's better to include a test which would run in non-PBM to first ensure that data gets outputted on disk in raw format and then, the same data doesn't get in on disk in raw format under private browsing. This would eliminate snappy compression argument.

2. It's also useful to create a test with two different origins trying to store same data and ensure that data on disk for both origins are different since the encryption keys used should be different.

3. Another tests would be to test the same origin creating couple of database with same data where we ensure that their on-disk data is different from one another because encryption keys are per database.

Below ones copied as it is from the testing strategy document

4. I don’t think we need to get full coverage of IDB put versus add, but I do think we want to make sure that we have coverage of the permutations inside ObjectStoreAddOrPutRequestOp::DoDatabaseWork as it relates to externally stored files. You’ll note that there’s an mDataOverThreshold branch which has us spill structured clone data that exceeds a pref-configurable threshold (kDefaultDataThresholdBytes is the default of 1 MiB for the “dom.indexedDB.dataThreshold” pref), and that’s an example of something that I think we would want to cause to happen. Note that we will snappy compress that data too, which potentially complicates things a little bit and may suggest that we want to set the pref to make it easier to trigger.

5. We probably also do want to think about verifying that the WAL is in fact encrypted in PB mode. The string check for the database should work with this too and we would probably want to check the unencrypted database too to make sure that we’re correctly ensuring that we’re deterministically checking before the database gets checkpointed. I think that probably means controlling the close of the database.

Comment 1

[Harveer Singh]

Number 1 and 5 are already implemented in test 'test_raw_IDB_data_ondisk' under file 'test_IDB_encryption_PBM.py'.