[Webkit-unassigned] [Bug 101745] New: WEBKIT_LOAD_FIRST_VISUALLY_NON_EMPTY_LAYOUT after WEBKIT_LOAD_FAILED status

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=101745

           Summary: WEBKIT_LOAD_FIRST_VISUALLY_NON_EMPTY_LAYOUT after
                    WEBKIT_LOAD_FAILED status
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: humitos at gmail.com


Created an attachment (id=173277)
 --> (https://bugs.webkit.org/attachment.cgi?id=173277&action=review)
This is an automatic test that works with my internet connection. Maybe a change to the milliseconds is needed in the GObject.timeout_add function call.

Hello people,

I'm working on Browse[1] (a Sugar/OLPC Activity) that uses WebKitGTK+ from Python.

I'm trying to fix a bug related with the Spinning Cursor[2]. We want to show the Spinning Cursor while the page is loading and show the Normal Cursor when the load finishes. So, I'm checking the 'load-status' property by connecting the signal 'notify::load-status' to a callback and setting the Spinning Cursor for WebKit.LoadStatus.PROVISIONAL, WebKit.LoadStatus.COMMITTED and WebKit.LoadStatus.FIRST_VISUALLY_NON_EMPTY_LAYOUT status.

So, if I press Esc (that calls WebKit.WebView.stop_loading) when the status is WebKit.LoadStatus.COMMITTED, it changes to WebKit.LoadStatus.FAILED, the 'load-error' signal is emitted (I get a web_error.code 302 here), the 'load-status' changes to 
WebKit.LoadStatus.FIRST_VISUALLY_NON_EMPTY_LAYOUT and the Spinning Cursor is shown again but the page is not loading anymore.

I'm asking here if this is a bug or not. Should the 'load-status' change to another status after WebKit.LoadStatus.FAILED? Is that OK? Is WebKit keep loading the page after a call to WebKit.WebView.stop_loading?

Thanks for your answers.

PS: I'm attaching a test case (not perfect, but it shows the strange behaviour)

[1] http://git.sugarlabs.org/browse
[2] http://bugs.sugarlabs.org/ticket/1434

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.