ubuntu-webapps-bugs team mailing list archive
-
ubuntu-webapps-bugs team
-
Mailing list archive
-
Message #01986
[Bug 1398941] Re: Tidy up LoadEvent mess
** Changed in: oxide
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1398941
Title:
Tidy up LoadEvent mess
Status in Oxide Webview:
Fix Released
Bug description:
Currently if a load fails, the renderer loads an error page. When this
happens, we get a sequence of load events that look like this:
type=started, url="http://invalid/"
type=failed, url="http://invalid/"
type=started, url="data:text/html,chromewebdata"
type=committed, url="http://invalid/"
type=succeeded, url="data:text/html,chromewebdata"
It's easy to filter out those events with
url=="data:text/html,chromewebdata" as being an error page (this URL
doesn't change), but the committed event in the middle is confusing
and difficult for an application to filter out.
There's a few potential solutions for cleaning this up:
- We could add an "isErrorPage" property to LoadEvent, which would be true for all of the last 3 events. We can detect that the committed event is an error page by checking the page type on the currently committed navigation entry.
- Alternatively, we could disable loading of the (currently non-existent / empty, but I'd like to provide a default page eventually) error page on the renderer side. This would get rid of these events entirely. Do we know whether QtWebkit or WebkitGTK provide a default error page?
- Another option would be to keep the error page but filter out the events. I'm less keen on this though, as it means we do commit a navigation entry but without emitting the appropriate committed notification.
To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1398941/+subscriptions
References