1776665 - Bugged content-prefs.sqlite make it impossible to change default preference of certain site

Status: NEW

(Toolkit :: Preferences, defect, P3)

Description

[byzod]

Attachment: bugged content-prefs.sqlite, deleted irrelevant entries

Info

Firefox automatically remembers zoom level of a site, but I noticed that one (only one) of them is always reset to a fixed zoom level whenever I visit it

After some research I found that

1. It's caused by bugged content-prefs.sqlite, it feels like that zoom level of said site is read-only, firefox can't change it
2. I deleted irrelevant entries in the SQL database but group-id 25 and 29 cannot be deleted for unknown reason

I'm not sure why and when my content-prefs.sqlite was broken, but I noticed this bug like months ago

Step to reproduce

1. Create a new profile, run it to generate default profile files
2. Download attachment content-prefs.sqlite and replace the one in said profile (or just copy it in there, if there's none)
3. Open https://chan.sankakucomplex.com/post/show/25675944 (nsfw), change zoom level to 70%
4. Refresh page

Expected result

5. Firefox remembers your active change, zoom level remains 70%

Actual result

5. Zoom level reset to 130%

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:gw, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[:Gijs (he/him)]

Marco, do you know what's wrong with this sqlite db and where/how we'd need to deal with that wrongness?

Comment 4

[byzod]

One more thing I forgot to mention: my pc was unstable and freeze/reboot very often few months ago before I bought a new one, I noticed many web page session loss after a reboot/freeze-and-force-reboot, even search engine loss for few times (I have to recover search.json.mozlz4 manually)

This might be related to the corrupted content-prefs.sqlite. fyi

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Setting low severity right now because from what I can tell here, it's a pretty rare event to corrupt this SQLite database.

Comment 6

[Marco Bonardo [:mak]]

(In reply to :Gijs (he/him) from comment #3)

Marco, do you know what's wrong with this sqlite db and where/how we'd need to deal with that wrongness?

Not much we can easily fix, PRAGMA integrity_check returns a few rows are missing from index, but reindex doesn't solve that. Trying to remove the entries shows a disk image is malformed error that usually means the table/row headers are broken. The reasons can be many, disk or memory corruption, lying filesystem...

Usually there's only 2 solutions to these issues:

1. Throw away the db, rebuild a new one starting from a data backup, if you have a data backup.
2. try to clone the database manually, by basically copying over the schema and the data to a new one. Places tries something like that, and ideally it could be done by any consumer https://searchfox.org/mozilla-central/rev/fa81b64fc1a339e2b2b1f6a8637a689916e13c4e/toolkit/components/places/Database.cpp#859-975.

The copy-over approach is portable as a more generic helper for all the databases. The problem is this cloning must happen on startup before consumers can access the database, or we'd need some solution to hot swap the sqlite connection in background, that seems unlikely. The other problem is detecting the failure, Places is doing that during weekly maintenance, but we also have bug 1125157 that may allow to detect a corruption when running a query (some corruptions are undetected at time of opening). I wonder if a simpler js solution could be implemented in Sqlite.jsm.