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.
  2. 18 Feb, 2017 2 commits
  3. 17 Feb, 2017 1 commit
  4. 16 Feb, 2017 1 commit
  5. 15 Feb, 2017 4 commits
  6. 14 Feb, 2017 5 commits
  7. 13 Feb, 2017 1 commit
  8. 12 Feb, 2017 7 commits
  9. 11 Feb, 2017 6 commits
  10. 09 Feb, 2017 3 commits
  11. 08 Feb, 2017 1 commit
  12. 07 Feb, 2017 1 commit
  13. 06 Feb, 2017 3 commits
  14. 05 Feb, 2017 3 commits
    • Inaki Larranaga Murgoitio's avatar
      Update Basque language · d7775cca
      Inaki Larranaga Murgoitio authored
    • Piotr Drąg's avatar
      Update Polish translation · 05cf0c44
      Piotr Drąg authored
    • Carlos Garcia Campos's avatar
      Allow to have different settings in web applications · 7f065b1c
      Carlos Garcia Campos authored
      Make org.gnome.Epiphany.web schema relocatable to be used by web apps.
      Settings in org.gnome.Epiphany.web schema are now per web app, allowing
      users to have different settings in the main epiphany instance and in
      every web applications installed. Newly created web apps inherit the
      settings from the main instance. To make this possible I also had to
      move some of the settings:
       - user-agent, remember-passwords and enable-smooth-scrolling has been
         moved from the main schema to web. The profile migrator will copy the
         values from the main schema to the web one. Settings are not actually
         moved, but copied marking the old ones as deprecated.
       - adblock-filters has been moved from web to main schema, because it's
         actually shared, web apps use the default profile filters. This is
         not migrated because it's very recent setting and probably everybody
         is using the default value anyway since it's not exposed in the UI
      When the profile migrator is run for the main ephy instance, we simply
      copy the values of the deprecated settings to its new location. When
      it's run for a web app we copy the settings from the main profile. If
      the migrator was not run for the main profile yet, we use the deprecated
      values instead. This way web apps will be ensured to have the same
      The app menu for web applications includes now the preferences item to
      show the preferences dialog. The dialog is the same as the main one,
      but with with the global options hidden.
      This patch also removes ephy_settings_ensure_schema_for_path() and
      relocatable schemas are configured automatically based on the current
      profile dir, making it less error prone.
  15. 04 Feb, 2017 1 commit