This isn't the right place. It could lead to these signals being
connected multiple times due to PSON.

Since WebKit r243434 [1][2], the web view's URI property might not be
updated during WEBKIT_LOAD_STARTED. For example, when on the
about:overview page, if we click on any overview thumbnail, the URI is
still ephy-about:overview at this point. WebKit internally knows the
URI is different, but it is hiding the change from us until
WEBKIT_LOAD_COMMITTED because it doesn't know if web content is
maliciously attempting to spoof the URI. The URI is now only expected to
be accurate if the load was initiated by API request, e.g.
webkit_web_view_load_uri(), and our code here doesn't know anything
about how the load was initiated, so we'd better not check the URI here
at all.

There were several regressions that I never noticed until today:

 (1) We freeze the history here improperly, since we incorrectly think
     that we are loading about:overview. Then the page we load doesn't
     make it into history.

 (2) For the same reason, we don't save a new snapshot of the page for
     the overview, resulting in stale snapshots persisting the next time
     the overview is opened.

 (3) We set the loading message in the floating statusbar to indicate
     that we are loading the currently-viewed page, rather than the page
     that is actually being loaded. To fix this, we can just set the
     label to "Loading...", without displaying any URL at all, until
     WEBKIT_LOAD_COMMITTED is reached.

These bugs only occur when the load is initiated by web content, or by
user interaction with web content. Loads triggered by API request should
be fine.

[1] https://trac.webkit.org/changeset/243434
[2] https://bugs.webkit.org/show_bug.cgi?id=194208

Carlos Garcia Campos authored Sep 03, 2019 and Michael Catanzaro committed Sep 03, 2019

Now that WebKit has PSON enabled, it's possible to have different web
processes for the same web view ID. When the view swaps processes, the
page created signal is emitted in the new process, and a new web
extension proxy is set.

This might fix #871

I'm seeing occasional criticals when a WebKitDownload outlives the
EphyDownload, so better protect here.


(cherry picked from commit f793d533)

Fixes #691


(cherry picked from commit 7e7aa0fb)

(cherry picked from commit 7be86b8b)

(cherry picked from commit 4ded9213)

Fixes #736


(cherry picked from commit cefc3e33)

(cherry picked from commit 28eee99a)

(cherry picked from commit 97bc80c6)

Michael Catanzaro authored Jan 07, 2019 and Michael Catanzaro committed Feb 20, 2019

Somehow we are getting EphyBookmarks objects deserialized without
initializing the tags property. I'm not sure how this happens. It even
happens for JSON corresponding to bookmarks that definitely have tags
set. Anyway, ephy_bookmark_get_tags() is used as if the result is not
nullable, so let's guarantee this and return an empty list instead in
this case.

This is a speculative fix for #612. It should fix the reported crash,
but it's possible it will only uncover a subsequent crash.


(cherry picked from commit 672cffa5)

Michael Catanzaro authored Nov 27, 2018 and Michael Catanzaro committed Feb 20, 2019

This is possible if the web view has not loaded anything yet.

Fixes #590

Alexandr Sidorenko authored Sep 25, 2018 and Michael Catanzaro committed Feb 20, 2019

(cherry picked from commit db1b1c60)

Michael Catanzaro authored Aug 31, 2018 and Michael Catanzaro committed Feb 20, 2019

I was confused why ~/.local/share/webkitgtk was being created in Ephy
Tech Preview, until I realized the only storage was being used for
accounts.firefox.com. Let's save this data under Epiphany's proper
cache and data directories.

Carlos Garcia Campos authored Jun 13, 2018 and Michael Catanzaro committed Nov 27, 2018

We were checking that the file is a directory instead of that is a
symlink.

This is broken and not ready to be enabled, but we think YouTube has
begun to require MSE to access WebM videos. So we're left with no
real choice here.

I just hit a crash where a history service callback executes improperly
after the EphyEmbedShell has been destroyed. Certainly not supposed to
happen. Make sure this never happens.

Tracking query removal fails to consider that the URI might not have a
hostname.

Between LOAD_STARTED and LOAD_COMMITTED, we show the security level of
the previously-loaded page, but the address of the page that is being
loaded. They need to match. Track the last committed load and display
its address instead.

Fixes #503

I introduced this warning recently when fixing the memory leak that was
here.


(cherry picked from commit 2d166afc)

If it returns a nonnull, zero-length string, then we leak it.

Gabriel Ivașcu authored Jun 12, 2018 and Michael Catanzaro committed Jun 13, 2018

This reverts commit 3c8cd638.

Also, increment SCHEMA_VERSION in ephy-gsb-storage.c.

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

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.

I can't see serious problems due to all the warning spam. All
deprecations are addressed in master already and are unfixable here.

I have no idea how I managed to mess this up so badly.

Fixes #33

We need to be way more careful when converting URIs to security origins.
This can fail. In this case, Chase used a valid URI javascript:void(0);
for its form action, which of course does not have any hostname and
therefore cannot be converted to a security origin. This is a legitimate
technique in order to prevent the web browser from actually submitting
the form. That doesn't even matter, because this is untrusted HTML and
the website can put whatever bogus data it wants there, so we'd better
be prepared to handle it.

The solution is to always use the page's origin for the target origin if
the form action cannot be converted to an origin. This is correct
because the target origin is just used as a heuristic when detecting and
filling the forms.

The same problem could, in theory, exist with the actual origin of the
page containing a form. It's not guaranteed that every page will have a
sane URI, e.g. when pages are opened by JavaScript. So, although I don't
have a...

This reverts commit c56294dd.

Seems this has had unintended consequences.

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