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.
ec60b89...
by
Carlos Garcia Campos <email address hidden>
web-view: remove the previous extension weak pointer before setting a new one
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.
