1. 19 Mar, 2017 1 commit
  2. 05 Mar, 2017 1 commit
  3. 24 Feb, 2017 1 commit
  4. 20 Feb, 2017 1 commit
  5. 19 Feb, 2017 3 commits
    • Michael Catanzaro's avatar
      embed-shell: Fix dumb return types · 93716067
      Michael Catanzaro authored
      93716067
    • Michael Catanzaro's avatar
      history-service: Fix multiple initialization race conditions · 2cb839ce
      Michael Catanzaro authored
      This started out as a project to fix the read-only service test I just
      added. Initializing two history service objects in a row was racy,
      because I needed the first history service to be initialized before
      creating the second one, but there was no way to ensure that. This was
      only an issue for this one test, though; real Epiphany browser mode of
      course only creates one history service, so I assumed it was not a big
      problem.
      
      Fix this first issue using a condition variable to ensure the GObject
      initialization doesn't complete until after the history service has
      actually created the SQLite database.
      
      In doing this, I discovered a second bug. The use of the condition
      variable altered the timing slightly, and caused the history filename
      property to not be set in time when entering the history service thread.
      In fact, it's kind of amazing that the history service ever worked at
      all, because there is absolutely nothing here to guarantee that the
      filename and read-only properties have been initialized prior to
      starting the history service thread. So the database filename could be
      NULL when opening the database, which is a great way to lose all your
      history. Also, it could also be in read-only mode here even if it is
      supposed to be read/write mode, which is going to cause failures after
      today's commits. Fix this by adding a constructed function and starting
      the history thread from there, instead of doing it in init. This means
      that the history thread will not be started until after properties have
      been set. Note that, while I could not reproduce this bug on my machine
      until after adding the condition variable to fix the first bug, that was
      just due to timing and luck; it was already broken before.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=778649
      2cb839ce
    • 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
  6. 05 Feb, 2017 1 commit
    • 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
         yet.
      
      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
      settings.
      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.
      7f065b1c
  7. 03 Feb, 2017 2 commits
  8. 05 Dec, 2016 1 commit
  9. 30 Nov, 2016 1 commit
  10. 04 Nov, 2016 1 commit
    • Michael Catanzaro's avatar
      Fix linking with WebKit trunk · 93914a5c
      Michael Catanzaro authored
      We forgot to link to nettle and hogweed. It only worked because WebKit
      was pulling them in via GnuTLS, but WebKit has now switched to gcrypt.
      
      Also, use the pkg-config variables in the proper place in tests.
      93914a5c
  11. 01 Nov, 2016 1 commit
    • Michael Catanzaro's avatar
      Remove private headers · 50dfe139
      Michael Catanzaro authored
      There's no public API anymore and no extensions. Having private headers
      years later serves no purpose and is just confusing.
      50dfe139
  12. 25 Oct, 2016 3 commits
  13. 08 Oct, 2016 3 commits
  14. 07 Oct, 2016 1 commit
  15. 28 Sep, 2016 3 commits
  16. 21 Sep, 2016 1 commit
  17. 07 Sep, 2016 1 commit
    • Michael Catanzaro's avatar
      Fix build on Debian systems · ec5b6c9b
      Michael Catanzaro authored
      I don't understand, but Debian uses different linker settings from the
      rest of the world, and the effect is that we have to explicitly link to
      libephymisc.la in multiple places, even though it's already included in
      libephymain.la and this shouldn't be necessary, else it will get
      stripped from the linker command line.
      ec5b6c9b
  18. 07 Aug, 2016 2 commits
  19. 09 May, 2016 2 commits
  20. 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
  21. 26 Feb, 2016 3 commits
  22. 20 Jan, 2016 1 commit
  23. 07 Jan, 2016 1 commit
    • Michael Catanzaro's avatar
      Use GdTwoLinesRenderer to display the location entry completion · b4ce4463
      Michael Catanzaro authored
      Accordingly, we get to remove Carlos's horrible hack adding markup to
      the completion model (which in MVC should only model, not contain
      style), and Claudio's horrible hack adding a bool property to make the
      markup optional (to avoid breaking the search provider, which also uses
      the completion model).
      
      The markup was originally moved to the completion model in order to
      remove the cell data function, which was being run continuously due to
      some bug. Because GdTwoLinesRenderer uses real cell attributes to
      display the title and url separately, we no longer need to worry at all
      about the task it used to perform -- merging the title and url into one
      string, with a newline and formatting markup to control size and color
      of the second line. GdTwoLinesRenderer takes care of this much more
      cleanly.
      
      The only user-visible change is that it is now possible to read URLs in
      the completion when the row is selected, as the gray is darker.
      Apparently some people can read it fine, but the color was too similar to
      the selection blue on the three monitors I tested.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=736364
      b4ce4463
  24. 27 Dec, 2015 2 commits
  25. 11 Dec, 2015 1 commit
  26. 09 Dec, 2015 1 commit