ubuntu-webapps-bugs team mailing list archive
-
ubuntu-webapps-bugs team
-
Mailing list archive
-
Message #01991
[Bug 1398941] Re: Tidy up LoadEvent mess
** Also affects: oxide/1.3
Importance: Undecided
Status: New
** Also affects: oxide/1.4
Importance: Undecided
Status: New
** Changed in: oxide/1.3
Assignee: (unassigned) => Chris Coulson (chrisccoulson)
** Changed in: oxide/1.4
Assignee: (unassigned) => Chris Coulson (chrisccoulson)
** Changed in: oxide/1.4
Milestone: None => 1.4.0
** Changed in: oxide/1.3
Milestone: None => 1.3.6
** Changed in: oxide/1.4
Status: New => Fix Committed
** Changed in: oxide/1.4
Importance: Undecided => Medium
** Changed in: oxide/1.3
Importance: Undecided => Medium
** Changed in: oxide/1.3
Status: New => In Progress
--
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
Status in Oxide 1.3 series:
In Progress
Status in Oxide 1.4 series:
Fix Committed
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