They're all broken due to changes in WebKit, not in Epiphany.

https://bugzilla.gnome.org/show_bug.cgi?id=787011

It's wrong to try to use the address from the title widget here, because
the user could edit it to say whatever he wants, and it will crash if
there is no text in the location entry. Instead, get the address from
the web view.

https://bugzilla.gnome.org/show_bug.cgi?id=785338

Christian Hergert authored Apr 06, 2017 and Michael Catanzaro committed Sep 05, 2017

We need to compare against the character, not the pointer which
is done immediately to the left of this comparison.

Accidentally deleted initialization of priv when backporting
aaf8763d

https://bugzilla.gnome.org/show_bug.cgi?id=787316

Don't call remove_from_destroy_list_cb, which modifies the destroy list,
when already iterating through the list.

https://bugzilla.gnome.org/show_bug.cgi?id=779180

Now that SQLite enforces read-only mode for us, bugs like this will be
uncovered....

https://bugzilla.gnome.org/show_bug.cgi?id=778649

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

Closing the connection is great, but not enough. We're leaking our
wrapper object.

https://bugzilla.gnome.org/show_bug.cgi?id=778649

We have assertions to ensure that several functions are only ever called
on the history thread. But the first such assertion, at the top of
run_history_service_thread, sometimes fails when running the tests. It
is racy. Use a mutex to fix this.

These assertions are actually executed at runtime for end users, so it's
surprising that nobody has ever reported a bug about this.

We also need to be sure to initialize the async queue before running the
history service thread. The mutex is needed as a memory barrier here, so
it's not possible to remove the mutex by removing the assertions except
in debug mode, which is something I considered.

https://bugzilla.gnome.org/show_bug.cgi?id=778649

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

This file is so careful to handle errors properly everywhere EXCEPT the
point where actual SQLite commands are executed. The history database is
pretty much totally broken right now; having error messages would be
helpful thank you!

Adrián Pérez de Castro authored Feb 03, 2017 and Michael Catanzaro committed Feb 08, 2017

This adds a few more cases to the escaping done when converting an AdBlock
non-regepx "simple pattern" from a rule into a GRegex. This patch does the
following:

- Adds escaping to some of the regexp metacharacters which were not being
  handled: (){}+.|\
- Adds support for using a vertical bar at the end of a pattern to anchor the
  match at the end.
- Adds support for using ^ to match a "separator character" (a non-letter,
  non-number, or one of _-.%).

This also adds as much comment lines as code, which in this particular case
is probably a good thing, so reading the code in the future does not need
checking each case against the GRegex documentation.

https://bugzilla.gnome.org/show_bug.cgi?id=777714

This is ephy *profile* migrator. It runs on a per-profile basis. i.e.
each web app runs migrators separately. So this migration step could run
once for a profile dir, then again far in the future when an old web app
is opened. But passwords are global state, not stored in the profile dir,
and we want to run this migration only once. This is tricky to fix, but
it's easier if we relax the constraint to "never run this migrator if it
has been run already for the default profile dir." That's because we don't
really care if a couple web app passwords get converted from insecure to
secure, which is not a big problem and indicates the user probably never
uses Epiphany except for web apps anyway. We just don't want all the user's
passwords to get converted mysteriously because he happens to open a web
app. So check the migration version for the default profile dir and abort
if this migrator has already run there. This way we avoid adding a new flag
file to clutter the profile dir just to check if this migrator has run.

https://bugzilla.gnome.org/show_bug.cgi?id=752738

Carlos Garcia Campos authored Nov 10, 2015 and Michael Catanzaro committed Feb 03, 2017

It always returns the main default dot dir, no matter what the current
profile is. This is needed because some private profiles could need to
use the default dot dir, for example, web applications.

I've mishandled this issue pretty badly. Incredibly, my previous patch,
which was intended to ensure we always normalize URIs to security
origins when working with form auth data, only fixed use of the form
auth data cache. It didn't actually fix any use of the secret service
itself. Fix that.

This commit notably removes support for mailman passwords, which is
making the code way too complicated and conflicts with the goal of
storing only security origins and not full URIs in the secret service.

Note: this normalization is way better than what we were doing before.
In particular, it incidentally fixes odd bugs like the URI framgment,
even the empty fragment #, being sufficient to trick our password
manager into storing separate passwords, so this should also make the
password filling significantly more reliable than it used to be. (Unless
you need per-URI passwords without a username, i.e. mailman passwords,
in which case you're just out of luck, sorry!)

https://bugzilla.gnome.org/show_bug.cgi?id=752738

Using just host is not sufficient, we need to have protocol and port as
well for matching based on security origin to work properly.

Unfortunately the existing code here was full of subtle errors: the
parameters named "uri" were actually passed hostnames from the web
extension, and not URIs at all. The code only worked as long as that
assumption held, but I broke it because I expected the URI parameters to
actually contain URIs. So fix this. Really pass URIs and not hostnames,
and properly convert them to security origins.

Thanks to Hussam for reporting this bug so quickly after it was
introduced. (As well as lots of other bugs in the past that I've rarely
credited him for in commit messages.)

https://bugzilla.gnome.org/show_bug.cgi?id=752738

All previously-saved passwords will now only be available to https://
origins. Users will have to manually enter their passwords once again in
order to save them separately for an insecure origin.

https://bugzilla.gnome.org/show_bug.cgi?id=752738

Diego Escalante Urrelo authored Jan 08, 2014 and Michael Catanzaro committed Feb 01, 2017

https://bugzilla.gnome.org/show_bug.cgi?id=672574

Diego Escalante Urrelo authored Mar 28, 2012 and Michael Catanzaro committed Feb 01, 2017

https://bugzilla.gnome.org/show_bug.cgi?id=672574

This prevents an active MITM attacker from enumerating all your saved
passwords. The attacker will now only be able to access passwords saved
on http:// sites. That's by design, though; users are now warned when
focusing insecure password forms and should think twice before saving
such passwords.

Unfortunately this does introduce a migration issue, in that no
previously-saved passwords will be available on https:// websites
anymore, and all previously-saved passwords will still be enumerable by
attackers. I'm not sure how to handle migration. We might be able to
handle it nicely by using the history service to guess whether a
password should be migrated from http:// to https://, but that is not a
simple project.

https://bugzilla.gnome.org/show_bug.cgi?id=752738

Currently the URI tester loads filters and patterns asynchronously,
which is racy as it means ads will sometimes not be blocked when a new
web process is loading its first page. Filter processing must always
complete before the first resource is requested, so do it synchronously.

This is already fixed in a better way on the master branch, so this
commit is for backports only.

https://bugzilla.gnome.org/show_bug.cgi?id=775736

The call to gdk_keymap_translate_keyboard_state doesn't seem to really
do much here, except change the way we have to test for Ctrl+Shift+T by
consuming GDK_SHIFT_MASK. In particular, the keyval returned is already
the keyval in the key event, so that's not really doing anything for us.
But this is what the GDK documentation tells us to do, so why not. The
important change here, as shown in the GDK documentation, is to mask out
all the modifiers except Ctrl/Shift/Mod1 so that we ignore virtual
modifiers like Meta that we really don't want to see.

This mostly but not completely fixes the bug where the alt-left/right
shortcuts for back/forward stop working. It fixes the regression where
these shortcuts stopped working after I introduced key event filtering.
It *does not* fix the issue that was originally reported, which is that
the shortcuts mysteriously stop working sometimes; it cannot fix that
original bug, because the key event filtering was not added until a
month after that bug was reported. Hence, I am not closing the issue
here. Something seems to be wrong in either GTK+ or in mutter, as
sometimes GTK+ apps stop receiving any input at all; it might or might
not be related.

https://bugzilla.gnome.org/show_bug.cgi?id=772437

GDK can set random bits in the state to indicate internal stuff. We have
to use GDK_MODIFIER_MASK to mask out its reserved values before trying
to look at the state.

https://bugzilla.gnome.org/show_bug.cgi?id=772437

Seems WebKit always handles these key combinations, breaking our
back/forward shortcuts.

Never replace a good session file with one that's known to be broken.

https://bugzilla.gnome.org/show_bug.cgi?id=768250

Michael Catanzaro authored Apr 13, 2016 and Michael Catanzaro committed Nov 20, 2016

Return a stale snapshot, then schedule creation of a new snapshot. This
way, we show a preexisting snapshot even if snapshot creation fails. The
new snapshot will be used only for future requests.

https://bugzilla.gnome.org/show_bug.cgi?id=763184

Michael Catanzaro authored Apr 29, 2016 and Michael Catanzaro committed Nov 20, 2016

Save the thumbnail mtime when saving thumbnails so it actually reflects
the mtime embedded in the thumbnail, not the time the page was saved in
the history service. This regressed in 0433ac9d. It's only noticeable now
due to 97547353, which has resulted in thumbnails regularly disappearing
from the overview.

https://bugzilla.gnome.org/show_bug.cgi?id=763184

This reverts commit 78bbf3d0.

Certain window and tab management shortcuts are reserved by Epiphany and
will never be delivered to the webpage, even though webpages should in
general be allowed to override Epiphany shortcuts (e.g. Ctrl+B in Google
Docs should embolden text and not open the old bookmarks dialog, Ctrl+I
should italicize text and not open a new incognito window).

https://bugzilla.gnome.org/show_bug.cgi?id=764653

The current code propagates the event to the web view, then chains up if
the web view doesn't handle the event. But chaining up causes GtkWindow
to propagate the event to the web view yet again. Surely we never want
to do that, so stop doing it.

I think there must be some other bug here, though, in WebKit, that
causes WebKit to sometimes do something with the event but then
propagate anyway, which is wrong. If I'm right, then WebKit is
unfortunately still broken, but this works around it in Epiphany and is
the right thing to do anyway, since sending the same event to the web
view twice is nonsense regardless of whether the web view propagates it
or not.

https://bugzilla.gnome.org/show_bug.cgi?id=764653

Yosef Or Boczko authored May 08, 2014 and Michael Catanzaro committed Nov 20, 2016

http://bugzilla.gnome.org/show_bug.cgi?id=729726

We had a check for this, but it got broken in do not track mode.