URL loading detection

[modeveci]

The detection of a selected URL has been successfully loaded or failed to load. Available signals from webkit: notify-uri load-changed load-failed

There are 3 use-cases;

• When a new domain URL (e.g: domain.com) load process is initiated, process seems to be straightforward:

  1. notify-uri with domain.com
  2. load-changed is called with these events order: WEBKIT_LOAD_STARTED, WEBKIT_LOAD_COMMITTED, WEBKIT_LOAD_FINISHED

• When loading url with a subdomain from the same domain domain.com (domain.com already loaded i.e: the scenario above is completed and trying to load such as domain.com/subdomain#app etc. ), the only callback which is being called is notify-uri:

  1. notify-uri with domain.com/subdomain#app

• When loading wrong/not-valid url from a new domain:

1. notify-uri with wrong not_valid_url
2. load-changed with WEBKIT_LOAD_STARTED
3. notify-uri with current url (domain.com) as the new url is wrong
4. load-failed with wrong not_valid_url

Could you please describe what is the proper way to handle success or failed url load detection? Why is there a notify-uri with current url in case of load-failed is not signalled yet?

[magomez]

@modeveci, in which version of wpe is this reproducible?

[modeveci]

wpe-2.38 and prior versions

[rychem]

@magomez @modeveci would you be kind to share any update for this ticket?

[magomez]

I've been giving a look to the sequence of signals that are emitted in both of the cases that you comment. As you mention, for the valid URL case, we get the notify-uri signal with the new URL, and then the load-changed one three times, for WEBKIT_LOAD_STARTED, WEBKIT_LOAD_COMMITTED and WEBKIT_LOAD_FINISHED.

For the wrong URL case, we have:

• notify-uri with the new URL
• load-changed with WEBKIT_LOAD_STARTED
• At this point, the load fails, so what WPE does is falling back to the previous page, as it won't be able to load the new one. This is why the URI is changed to point to the previous page and we get the notify-uri signal with the previous page.
• Then we get the load-failed signal indicating that the new page has failed to load.
• And finally we get the load-changed signal indicating WEBKIT_LOAD_FINISHED for the previous URL, as we have fallen back to it and it's completely loaded.

So, ir order to know whether the page was able to load or not.

• If the page loads, there's no load-failed signal, and we'll get the three load-changed signals. Getting the URL inside the handlers of those signals with webkit_web_view_get_uri() will always give you the URL we're trying to load.
• If the page fails there's a load-failed signal for the invalid URL, and then a load-changed signal with WEBKIT_LOAD_FINISHED. If you get the URL at that point with webkit_web_view_get_uri(), you'll get the old URL.

It may happen that a redirect can change the URL we're trying to load. In that case, the view's URL will change to reflect the redirected one, and you'll get a load-changed signal with WEBKIT_LOAD_REDIRECTED. In that case, you have to take into account that the load-failed signal will come for the redirected URL and not the original one, or that the URL that you get with webkit_web_view_get_uri() is the redirected one as well.

[magomez]

One detail more, in case it's interesting for you. The load-failed callback returns a gboolean. By returning TRUE, the default handler is not executed, and you have the behavior that you explained. If that callback returns FALSE, then the default handler is executed after your callback, which loads an error page. In this case you'll have the same behavior than before, but there will be some extra signals that correspond to the error page that's shown:

• notify-uri will happen with the invalid URL again.
• load-changed will happen for WEBKIT_LOAD_STARTED, WEBKIT_LOAD_COMMITTED and WEBKIT_LOAD_FINISHED for the invalid URL.

[modeveci]

Thank you @magomez for info. Closing the ticket!