Claudio Saavedra authored Oct 03, 2014 and Michael Catanzaro committed Oct 17, 2014

Whatever is searched in a incognito session shouldn't go to the
history, not even if this will be deleted afterwards.

As recommended by Giovanni in bug #736449

Search providers are supposed to quit after running for a few seconds.

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

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

The "form-auth-data-save-requested" signal was not properly disconnected
as the g_signal_handlers_disconnect_by_func() was using the wrong
object.

The "allow-tls-certificate" signal was not disconnected at all.

The "notify::favicon" was needlessly disconnected (it will be
disconnected when the web view disappears).

And the "cleared" signal for the history service was never disconnected.

g_signal_connect_object() should ensure that all the signals we connect
to that have the web view as data are disconnected when the web view is
destroyed.

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

Conflicts:
	embed/ephy-web-view.c

The uri-tester is created from the web extension. When created, it opens
~/.config/epiphany/adblock/filters.list for reading in
uri_tester_load_filters(), then calls uri_tester_set_filters() with the
read filters. uri_tester_set_filters() unconditionally calls
uri_tester_save_filters(), so we immediately write back what we read to
filters.list. But this is racy: if you are starting multiple web
processes at the same time, such as when opening epiphany with multiple
saved tabs, then one process may open the file for reading after another
has opened it for writing (which clears the file) but before the filters
have been written back to the file, so now one UriTester instance has an
empty list of filters, and it will immediately write back that empty list.

The original list is completely doomed because the only time we ever
write to filters.list is immediately after the filters are read, since
we do not support modifying filters. That's right, these writes are
NEVER necessary, so let's just remove them completely so we can be
completely sure the problem is gone.

Now we have an ununsued uri_tester_save_filters() function, but I don't
want to get rid of it quite yet as I do want to support at least a
couple different types of filters in the future (for tracking
protection). Also, there are already other unused functions here as
well, so one more is no difference for now, but refactor is imminent.

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

This reverts commit 32e2936e.

ephy-location-controller has some suspect code to lock the location
entry, preventing it from being changed when the current web page
changes. This is contrary to the behavior of Firefox, which immediately
updates the location entry when the page changes. I think Firefox's
behavior is less confusing, since it ensures the correct address is
always displayed, but I guess the intent of Epiphany's behavior is to
not change the address if the user is currently typing one.

The problem occurs when the location entry is focused while a new page
is loading: then the old address remains in the location entry, while
the title box subtitle gets updated to the new address. Fix this desync
by always updating the location entry address when the location entry is
unfocused. This means the location entry will only have the incorrect
address as long as it is visible, and will be updated to the correct
address when the title box is shown.

We might additionally want to remove all the locking code so that the
address is always immediately updated.

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

This reverts commit a47608b0.

String freeze...

The web view can be destroyed out from under us, so we need to use a
weak reference to determine if it is still alive.

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

This reverts commit 005ce536.

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

This reverts commit 7eabfe44.

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

This reverts commit 5c8005ec.

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

That will help debugging future issues with extensions not being found.

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

The UI side relies on having the name of the owner to find the extension on
its linked list. If we start emiting signals before that has been acquired,
we will miss page created signals.

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

From some reason it look like the disconnect by sig_id
plot a warning here, since we can to disconnect by func
it better here.

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

These binding could already have been destroyed. It might be safe to
simply remove the calls to g_clear_object, since they are not needed for
memory management, but then the bindings might not be unbound if a new
web view is set before the old one is destroyed.

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

Carlos Garcia Campos authored May 21, 2014 and Carlos Garcia Campos committed Jun 12, 2014

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

Siyu Yang authored May 29, 2014 and Kat committed May 30, 2014

Added a page to list the keyboard shortcuts, according to the code:
https://git.gnome.org/browse/epiphany/tree/src/ephy-window.c#n102

The added page is linked to the first section 'Getting started' of
the index page.

Bugzilla link: https://bugzilla.gnome.org/show_bug.cgi?id=730503

Fixes a crash with a URI such as:
http://www.test.com/?some&valid&query

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

Implement Dan Winship's approach to detecting unwanted parameters
by reusing the original key pair values (without decoding/encoding)
when they are wanted, and simply dropping them when not.

See https://bugzilla.gnome.org/show_bug.cgi?id=724724#c14

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

Marco Barisione authored May 14, 2014 and Carlos Garcia Campos committed May 21, 2014

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

Marco Barisione authored May 14, 2014 and Carlos Garcia Campos committed May 21, 2014

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

Marco Barisione authored May 14, 2014 and Carlos Garcia Campos committed May 21, 2014

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

Carlos Garcia Campos authored May 20, 2014 and Carlos Garcia Campos committed May 20, 2014

We are currently decoding/encoding the uri query and returning it
unchanged when it doesn't have garbage. We should return NULL instead in
such case.
This fixes the session management issues in some sites like gmail, but
because the URLs processed don't actually have garbage. A URL with
garbage and an underscore will still fail. This patch adds a unit test
cover that particular case.

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

Previously, the first page loaded in a webview would be done with
before the user had any chance to type an address, so it was safe to
assume that any typed address could be cleared during page loads,
as they would always come from previously loaded pages.

Now that the process of creating a webview is different and
involves spawning a web process that needs to be ready before
the initial page can be loaded, it might be possible for users
to type an address before this is ready. This breaks the previous
assumption and needs to be dealt with, in order to avoid
cleaning up typed text during the initial page load.

Additionally, it makes sense to make set_address() a no-op if
the given address is the same as the currently loaded.

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

This reverts commit 0eeb2c28.

This reverts commit 2881a322.

This reverts commit c3c38edb.

This reverts commit b3f380d4.