GNOME Bugzilla – Bug 679047
[WebKit2] Issues with notify::uri and anchor links
Last modified: 2012-09-27 09:44:25 UTC
The only (?) way we have in WK1 and WK2 to update the URI when anchor links are clicked is to listen to notify::uri, since they do not trigger actual navigation events. In WK1 we'd listen to the signal and just update our URI if it was different from the one we already had. This does not work in WK2 though, since: - notify::uri is now fired more often, in particular it is fired *before* the navigation process in normal loads even starts. - This means there is no way to tell the difference, AFAICT, between clicking on an anchor link (no load is happening, URI is updated) and the notify::uri you get when a load is about to start (no load is happening either, the URI is also updated). If we want to follow what notify::uri tells us regardless of the state of the load we need to change some things in EphyWebView, since there are some corner cases that were relying on the WK1 behavior. I'm investigating what's the best thing to do here and doing some refactorings/cleanups while I do that, opening this bug mostly for reference. At this moment the visible effect of all this is that clicking anchor links does NOT update the URI in the entry in WK2.
Current approach is good, the only problem is that we rely on is-loading property of EphyWebView that is not accurate, because it's set to TRUE when load-changed is emitted with STARTED event, and at that point the load has already started. Current approach would work if we could ask WebKit whether it's loading something or not. See WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=97330 With that API we could either keep current code but using webkit_web_view_is_loading() instead, or connect to notify::is-loading and disconnect notify::uri when is-loading is TRUE and connect it again when it's false, so that we are only notified about uri changes when the load has finished (anchor links). We already update the uri manually during the load operation when it's committed.
Created attachment 225247 [details] [review] Patch Using webkit_web_view_is_loading() instead of our own guess fixes this problem.
Review of attachment 225247 [details] [review]: Awesome.