WebView.loading should be false when receiving a LoadEvent with type == TypeStopped

Bug #1290821 reported by Olivier Tilloy on 2014-03-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Medium
Chris Coulson

Bug Description

When receiving a LoadEvent (through the loadingChanged signal) of type LoadEvent.TypeStopped (when a load in progress was stopped by the user), while in the signal handler, the 'loading' property of the webview hasn’t been updated to false.
As a consequence, properties that are bound to 'loading' do not get updated accordingly (querying the value of the property afterwards, outside of the signal handler, correctly returns false).

I’m going to link a branch with a failing unit test for the issue.

Changed in oxide:
importance: Undecided → Medium
status: New → Triaged
Chris Coulson (chrisccoulson) wrote :

The issue here is that the signal we use for notifying of changes to WebView.loading (WebView.loadingChanged) comes from the wrong source. With hindsight, it would have been better to have 2 separate signals (one for notifying of changes to WebView.loading, and another one to deliver LoadEvents).

I think the way to fix this is to split the existing signal in 2:

- Introduce WebView.loadingStateChanged to notify of changes to WebView.loading.
- Introduce WebView.loadEvent for delivering LoadEvent's

The existing WebView.loadingChanged will be kept around, so applications that do "onLoadingChanged {}" or "WebView.loadingChanged.connect()" will continue to work exactly the same (albeit, with this bug)

Changed in oxide:
assignee: nobody → Chris Coulson (chrisccoulson)
status: Triaged → In Progress
Changed in oxide:
milestone: none → branch-1.3
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers