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

Bug #1290821 reported by Olivier Tilloy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Fix Released
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
Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.