Open Bug 1517145 Opened 9 months ago Updated 3 months ago

about:newtab indexeddb data grows to excessive size

Categories

(Firefox :: Messaging System, defect, P2)

defect

Tracking

()

Tracking Status
firefox66 --- affected
firefox67 --- fix-optional

People

(Reporter: mossop, Unassigned, NeedInfo)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

I was investigating some issues my wife is having with her Firefox profile and happened to notice that it was quite large. Turns out the indexed db store for about:newtab (storage/default/about+newtab) is taking up 1.1GB of space. This seems too large. What on earth are we putting in there?
:andreio, could you investigate this, please?
Flags: needinfo?(andrei.br92)
Assignee: nobody → andrei.br92
Flags: needinfo?(andrei.br92)
Iteration: --- → 66.3 - Jan 7 - 20
Priority: -- → P1

@mossop is it possible to share that data? I was not able to reproduce the issue. Activity Stream only stores some boolean preferences in IndexedDB, no sensitive data is present.
Also it might be interesting to list the timestamps of those files (were they all created at the same time or has it been gradually growing).

Flags: needinfo?(dtownsend)

Have you come across a similar issue? Some follow up information

most of the files are in <profile>/storage/default/about+newtab/idb/3312185054sbndi_pspte.files. Each file is only 4-5MB but there are 220 of them
indexeddb inspector shows basically no data for Activity Stream

That last part makes me think it might not be a AS specific bug, this code has been in production for several releases without any similar reports

Flags: needinfo?(bugmail)

Maybe a sanity check of visiting https://firefox-storage-test.glitch.me/ and seeing if everything is green?

(In reply to Andrei Oprea [:andreio] from comment #2)

@mossop is it possible to share that data? I was not able to reproduce the issue. Activity Stream only stores some boolean preferences in IndexedDB, no sensitive data is present.

Here: https://drive.google.com/file/d/1ZGAyOO3OixlDRpiT05mmil_-x7_KUruS/view?usp=sharing

Also it might be interesting to list the timestamps of those files (were they all created at the same time or has it been gradually growing).

Unfortunately I no longer have this, looks like the timestamps show when I copied the files from my wife's machine and the profile has been since deleted from her machine.

Flags: needinfo?(dtownsend)

The contents of the database indicate two things are going on:

  • The key "snippets" has a 4 megabyte string inside that seems to be serialized HTML that contains a bunch of SVG images that are stored inline as base-64 data URL's. This gets stored as a file on disk because, for efficiency, IndexedDB stores large structured clones as externally stored Blobs.
  • There may be a very serious bug in IndexedDB related to external storage of structured clonesbecause there should only be one of those giant 4 megabyte files on disk.

:mossop, because the "snippets" key appears to be the persisted state of the activity stream UI at various points during use, it is in fact likely to contain private information and I would suggest deleting/revoking access to the archive. I am marking this bug as a security bug in the interim to avoid further potential exposure of the contents. I don't seem to have the ability to mark just the single comment as security sensitive. Note that I haven't actually seen any user-private data from the blobs and don't intend to, so this is not any reaction to any private information, I'm just acting out of caution for private information.

I do not believe we need to perform any further analysis of the file. At the raw SQLite level, the contents of the "file" table is (from .dump):
INSERT INTO file VALUES(403,1);

And the sole row referencing a file is:
INSERT INTO object_data VALUES(1,X'30746f6a7171667574',NULL,'.403',4294967296);
(Noting that the opaque string is a fancy encoding of "snippets").

Group: firefox-core-security
Flags: needinfo?(shes050117)
Flags: needinfo?(jvarga)
Flags: needinfo?(dtownsend)
Flags: needinfo?(bugmail)

I have revoked access to the file (it was already only visible to mozilla staff).

Group: firefox-core-security
Flags: needinfo?(dtownsend)

It would be helpful to see directory listing of <profile>/storage/default/about+newtab/idb/3312185054sbndi_pspte.files

Attached file file listing

Probably not related to this bug, but note that the broken profile (missing fileInfo) I got in bug 1515069 is also for about+home, the database is used for snippets, and the size of the problematic files in the xxx.files directory is 4.8 + 4.8 MB (there are two files).

Iteration: 66.3 - Jan 7 - 20 → 67.1 - Jan 28 - Feb 10
Iteration: 67.1 - Jan 28 - Feb 10 → 67.2 - Feb 11 - 24
Priority: P1 → P2
Blocks: 1513279
Assignee: andrei.br92 → nobody

I believe that :janv has come up with a workaround for this issue, could you put more details here, :janv?

Priority: P2 → P1
Iteration: 67.2 - Feb 11 - 24 → 68.1 - Mar 18 - 31
Priority: P1 → P2
Iteration: 68.1 - Mar 18 - 31 → ---

Yeah, we need to fix this.

Blocks: 1541370
Flags: needinfo?(jvarga)

It's unclear to me how or when this bug will be handled. Is this something DOM is doing as part of 1541370 (and thus we should assign and prioritize as part of that) or something that AS will handle with janv's guidance?

We should coordinate this -- whatever it is we do or find out -- with bug 1522188.

Flags: needinfo?(jvarga)
See Also: → 1522188

I'm afraid this is a low level IndexedDB bug and must be handled by someone from workers & storage team.

For now, you can try to set "dom.indexedDB.dataThreshold" pref to "-1".

Flags: needinfo?(jvarga)

Is this situation unique to mossop's case? Do we have telemetry on the size of the snippets db? How urgent of an IDB change is this?

Flags: needinfo?(najiang)

(In reply to Andrew Overholt [:overholt] from comment #15)

Is this situation unique to mossop's case? Do we have telemetry on the size of the snippets db? How urgent of an IDB change is this?

We don't have telemetry coverage on the db size in Activity Stream, can't tell if it's common or not.

The other telemetry shows that the "INDEXEDDB_OPEN_FAILED" and "TRANSACTION_FAILED" are the most frequent IDB failures seen in Activity Stream. Per asuth, the former is related to IDB quota manager, and the team has been working on the fix to it. Not sure if the transaction failure has to do with this issue.

Flags: needinfo?(najiang)
Component: Activity Streams: Newtab → Messaging System
You need to log in before you can comment on or make changes to this bug.