1. 22 Sep, 2017 1 commit
  2. 24 Aug, 2017 2 commits
  3. 20 May, 2017 1 commit
  4. 02 Apr, 2017 1 commit
    • Iulian Radu's avatar
      add-bookmark-popover: Save bookmarks on both popover show and close · 22bdf160
      Iulian Radu authored
      Due to the fact that a bookmark is added to the manager when the popover
      is closed, a press on the bookmark button followed by a press on the "Remove
      bookmark" button causes a crash because ephy_bookmarks_manager_remove_bookmark()
      tries to find the new bookmark which has not been added yet.
      
      Revert to the original behaviour where a bookmark is saved immediately
      after pressing the star, but also save the bookmark when the popover is
      closed in case the user changed something while the popover was open
      
      https://bugzilla.gnome.org/show_bug.cgi?id=780851
      22bdf160
  5. 01 Apr, 2017 3 commits
  6. 24 Mar, 2017 1 commit
  7. 23 Mar, 2017 2 commits
  8. 24 Feb, 2017 2 commits
  9. 19 Feb, 2017 12 commits
    • Michael Catanzaro's avatar
    • Michael Catanzaro's avatar
      913dbc30
    • Michael Catanzaro's avatar
    • Michael Catanzaro's avatar
    • Michael Catanzaro's avatar
      bookmarks-popover: Fix removing tag while in tag detail view · dd589f66
      Michael Catanzaro authored
      There were two problems here:
      
      (1) The code to handle removing the bookmark from the tag view was
      guarded by the code that checks if the bookmark is the last one
      remaining in the tag view. That is, it can never be reached except when
      we're about to exit tag view anyway. Fix that by moving it outside the
      top conditional, where it never belonged.
      
      (2) With that fixed, the code now removes the bookmark from the tag
      detail view even if the tag removed does not correspond to the current
      tag detail view. That's bogus. Check the current view's tag before
      removing the bookmark row.
      dd589f66
    • Michael Catanzaro's avatar
      bookmarks-popover: Properly remove bookmark from tag detail · fe31197f
      Michael Catanzaro authored
      When a bookmark is removed, we need to also remove it from the tag
      detail.
      fe31197f
    • Michael Catanzaro's avatar
      bookmarks-popover: Switch away from tag detail view only if necessary · 99a48a54
      Michael Catanzaro authored
      If we are deleting a tag while in tag detail view, only switch away from
      detail view if the tag we are deleting is the tag we are currently
      viewing. Otherwise it's confusing and dumb.
      99a48a54
    • Michael Catanzaro's avatar
      bookmarks-popover: fix crash when deleting tag · f630032e
      Michael Catanzaro authored
      We want to do this once after processing all bookmarks, not once for
      each bookmark... this was causing crashes when deleting a tag while
      viewing a particular tag's list of bookmarks.
      f630032e
    • Michael Catanzaro's avatar
      bookmarks-popover: Ignore smart bookmarks in tag added/removed callbacks · 1a09c3ec
      Michael Catanzaro authored
      Bookmarks popover is not designed to handle smart bookmarks. They're
      just going to make it crash.
      1a09c3ec
    • Michael Catanzaro's avatar
    • Michael Catanzaro's avatar
      Use emblem-favorite-symbolic icon for favorites · 03b5ca5a
      Michael Catanzaro authored
      This doesn't match the mockups, but it helps clarify that favorites are
      different from other bookmarks. Favorites are your favorite bookmarks!
      <3
      
      https://bugzilla.gnome.org/show_bug.cgi?id=778849
      03b5ca5a
    • 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
  10. 24 Jan, 2017 6 commits
  11. 22 Jan, 2017 5 commits
  12. 17 Jan, 2017 4 commits