• Michael Catanzaro's avatar
    Fix search provider horribly breaking history service · 9771c52f
    Michael Catanzaro authored
    If the search provider is running, all database transactions will fail
    because the search provider will take a write lock on the database.
    Ouch! This is worth a good string of profanities....
    
    Notably, this causes opening the database to fail if you searched for
    anything in the shell overview in the minute prior to starting Epiphany.
    (One minute is our search provider timeout.) Then no history will ever
    get saved, ever. I think. Something like that.
    
    So, although our history service has read-only mode, it's enforced at
    the history service level, not the SQLite connection level. SQLite
    actually has a read-only mode, which we are not using, and which we need
    to use in the search provider if we want to have any chance of reliably
    saving history.
    
    Accordingly, give EphySQLiteConnection a mode property, to indicate
    whether it is in writable mode or read-only mode. Teach all callers to
    set it properly. Use it, rather than a boolean, when creating the
    EphyHistoryService, since boolean parameters are hard to read at call
    sites. And actually put the underlying SQLite connection in read-only
    mode when set.
    
    Don't open transactions or ever attempt to rollback in read-only mode,
    because that doesn't make any sense. This should never have been
    happening due to the history service level read-only checks, but it
    should be enforced at the SQLite connection level now, too.
    
    Avoid initializing tables when opening the database in read-only mode.
    This is obviously writing to the database, and now that we really have a
    read-only SQLite connection it fails. As it should.
    
    SQLite connection creation will now fail in case the connection is
    read-only and the database does not yet exist; it will no longer be
    created anyway. So handle this case gracefully. It's fine for the
    history service to return nothing in this case. This has the small
    advantage that the history thread will quit immediately after it's
    created in this case, so it's not constantly running if there's no
    history in incognito mode anymore. To check for this condition, we
    expose the underlying SQLite error; previously, only the error message
    was exposed outside of EphySQLiteConnection. Exposing the error isn't
    really necessary or sufficient, though, since it's super generic and we
    have to check if the file actually exists on disk anyway.
    
    Test it. Ensure that a read/write history service functions properly if
    it's running at the same time as a read-only history service. Using two
    read/write services here fails very badly, but when one of the services
    is read-only it works fine.
    
    Also, remove the original read-only service test. It only ever tested
    that creating a read-only history service with an empty history database
    would succeed. And, as I just explained, that fails now.
    
    Lastly, stop running a second history service for the search provider.
    It needed its own once upon a time when the search provider did not run
    an EphyShell instance. That changed when we stopped using the default
    web context, because nothing works without EphyEmbedShell now, as all
    sorts of places need it to get the embed's web context. And since
    EphyEmbedShell runs its own history service, the search provider can
    just use that now instead of running its own separate one.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=778649
    9771c52f
ephy-sqlite-connection.c 7.32 KB