1. 01 Jul, 2018 1 commit
  2. 28 Jun, 2018 1 commit
  3. 26 Jun, 2018 1 commit
  4. 24 Jun, 2018 2 commits
  5. 15 Jun, 2018 1 commit
  6. 13 Jun, 2018 2 commits
    • Michael Catanzaro's avatar
      uri-tester: Fix cache lookups when URI is not matched · d7fefdec
      Michael Catanzaro authored
      This regressed in e17dc362.
      g_hash_table_lookup() cannot distinguish between a missing value and a
      NULL value. We are storing a NULL pointer (GINT_TO_POINTER (FALSE)) to
      indicate that the URL is not a match, so the end result is that instead
      of a cache hit indicating we should return FALSE, we instead get a cache
      miss and then have to manually determine that we need to return FALSE.
      
      This should be a performance fix only, it should not affect correctness.
      
      Fixes #37
      d7fefdec
    • Michael Catanzaro's avatar
      uri-tester: Fix urlcache memory leak · 0e11a1da
      Michael Catanzaro authored
      Something went wrong with the git history related to e17dc362, and we
      wound up allocating a string here that will never be freed. Whoops.
      
      Then we pass it through GPOINTER_TO_INT() even though it is really a
      random pointer and not going to be a meaningful integer value, and
      return it as a gboolean. So we have a gboolean that is neither TRUE nor
      FALSE, which is bad. But fortunately, it looks like it's never
      explicitly compared to TRUE, so there should have been no behavioral
      issue besides the leak.
      
      This is related to #37.
      0e11a1da
  7. 12 Jun, 2018 2 commits
  8. 07 Jun, 2018 1 commit
  9. 03 Jun, 2018 1 commit
  10. 01 Jun, 2018 2 commits
  11. 29 May, 2018 2 commits
  12. 25 May, 2018 1 commit
  13. 23 May, 2018 1 commit
  14. 30 Apr, 2018 1 commit
    • Adrián Pérez de Castro's avatar
      Simpler custom CSS theming for non-Adwaita themes · 6406d184
      Adrián Pérez de Castro authored
      In particular, the theming for the incognito windows tends to look odd
      with themes other than Adwaita. It is possible to load different CSS
      resources depending on the selected theme by handling changes to the
      GtkSettings::gtk-theme-name property: this splits the CSS into a
      "shared.css" part which contains the rules which play well with most
      themes, and an "Adwaita.css" which builds upon the shared CSS rules
      and is loaded only for the Adwaita theme. The CSS code is still
      generated from SCSS, with definitions used by SCSS snippets moved
      into a new _definitions.scss file to avoid repeating them.
      
      Note that instead of manually handling theme changes, EphyEmbedShell
      is changed to inherit from DzlApplication (instead of GtkApplication),
      which already implements the desired CSS resource loading behaviour.
      This makes the existing CSS loading code unneeded, and therefore it
      is removed. Also, the resources are moved into the resource path
      /org/gnome/Epiphany/themes as expected by DzlApplication.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783912
      6406d184
  15. 26 Apr, 2018 2 commits
  16. 19 Apr, 2018 2 commits
  17. 18 Apr, 2018 1 commit
  18. 14 Apr, 2018 2 commits
  19. 10 Apr, 2018 1 commit
  20. 09 Apr, 2018 1 commit
    • Michael Catanzaro's avatar
      Don't search on ' or / · 543fd1ac
      Michael Catanzaro authored
      This causes problems in practice on certain websites (e.g. Facebook,
      Riot) where the key press is handled by both the web page and the
      browser. I'm guessing these sites are not using normal text entries.
      Anyway, these are really niche shortcuts when the much more common
      Ctrl+F is available, which does not have any web compat implications.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=795083
      543fd1ac
  21. 05 Apr, 2018 1 commit
  22. 29 Mar, 2018 3 commits
    • Michael Catanzaro's avatar
      Remove auto-open downloads feature · a41416c9
      Michael Catanzaro authored
      This is inherently unsafe because a webpage can download a malicious
      file without user interaction, and trust it will open automatically in
      a vulnerable application.
      
      We will continue to download files automatically, despite the various
      Chrome hacks from last year proving that this can be abused via tracker
      and GNOME desktop thumbnailers. Tracker now mitigates this risk using
      libseccomp, and GNOME desktop thumbnailers are now run under bubblewrap.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=794681
      a41416c9
    • Michael Catanzaro's avatar
      Remove the HTTPS Everywhere support · 762c7bc9
      Michael Catanzaro authored
      It's experimental and not supposed to be enabled, but got turned on in
      Arch, so best move it to a sidebranch for now. I'm not sure if we'll
      ever bring it back, though. HTTPS Everywhere was a great idea a few
      years ago, when it was common for websites to offer experimental support
      for HTTPS but not redirect users to it automatically. Nowadays, such
      websites almost always problems, such as blocked mixed content or invalid
      HTTPS certificates, or have disabled HTTPS since the ruleset was
      written. That means, to do this right, we have to ignore TLS errors --
      including in subresources -- and disable mixed content blocking. This
      scheme to preserve web compatibility needs to be implemented before we
      consider bringing it back.
      
      Meanwhile, more and more websites are redirecting to HTTPS and are
      nowadays configured to handle this correctly, so the necessity of HTTPS
      Everywhere is lower now than ever before, and decreasing fast. Moreover,
      if a website implements its own proper support for HTTPS and starts
      automatically redirecting users to it, but the ruleset is not updated,
      then under the scheme I propose above, the ruleset would become a way of
      *reducing* security for websites once they've begun to support HTTPS. So
      I'm skeptical that we should bring this back at all. Times, they are
      a-changing.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=794803
      762c7bc9
    • Michael Catanzaro's avatar
  23. 27 Mar, 2018 1 commit
  24. 26 Mar, 2018 2 commits
    • Michael Catanzaro's avatar
      Remove some code that's not doing anything · f0e577eb
      Michael Catanzaro authored
      Way back in the day, we used to clear the back/forward list when
      clearing history. This is no longer possible, and that's not a problem
      at all.
      f0e577eb
    • Michael Catanzaro's avatar
      Snapshot only the most-visited pages · 7ae2cefb
      Michael Catanzaro authored
      My ~/.cache/epiphany/thumbnails is 287 MB large, and this directory did
      not exist at all until a couple months ago. It's also pretty bad for
      privacy that we currently save a PNG snapshot of every webpage ever
      visited on disk, even if we make an effort to delete them when removing
      history.
      
      Let's take snapshots only for the top 14 pages in history. The cache can
      still grow without bound, but it should never become very large with
      this limitation.
      7ae2cefb
  25. 25 Mar, 2018 1 commit
  26. 11 Feb, 2018 1 commit
  27. 29 Jan, 2018 1 commit
  28. 27 Jan, 2018 1 commit
  29. 18 Jan, 2018 1 commit