1. 19 Feb, 2017 1 commit
    • 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
  2. 08 Oct, 2016 1 commit
  3. 29 Mar, 2016 1 commit
    • Michael Catanzaro's avatar
      Uncrustify · 9ccb9da9
      Michael Catanzaro authored
      For a better future. Apologies when your 'git blame' resolves to this.
      
      I'm actually really impressed how well uncrustify works. This required
      only a little one-time manual work to avoid extra space in 'else   {'.
      
      This breaks function prototype alignment, but we should get rid of most
      of those anyway.
      
      We decided to start aligning function parameters, like other GNOME
      applications. It looks nicer this way, and I couldn't teach uncrustify
      the previous Epiphany style.
      9ccb9da9
  4. 07 Dec, 2015 1 commit
  5. 06 Mar, 2012 2 commits