[Webkit-unassigned] [Bug 153210] ASSERTION FAILED: !m_mainFrame->coreFrame()->loader().frameHasLoaded() || !m_pendingNavigationID when reloading page while a page is loading

[bugzilla-daemon at webkit.org]

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

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |achristensen at apple.com,
                   |                            |cdumez at apple.com,
                   |                            |cgarcia at igalia.com
          Component|WebKit Gtk                  |WebKit2
            Summary|[GTK] ASSERTION FAILED:     |ASSERTION FAILED:
                   |!m_mainFrame->coreFrame()-> |!m_mainFrame->coreFrame()->
                   |loader().frameHasLoaded()   |loader().frameHasLoaded()
                   ||| !m_pendingNavigationID   ||| !m_pendingNavigationID
                   |when reloading page while a |when reloading page while a
                   |page is loading             |page is loading

--- Comment #2 from Carlos Garcia Campos <cgarcia at igalia.com> ---
This is not GTK specific. This is what happens:

 1. gnome.org request is made
 2. webkit.org request is made
 3. gnome.org request is stopped, so finished is called (didFailProvisionalLoad in C API)
 4. Reload is called, but the URL is empty because the provisional load failed.
 5. In the web process WebPage::reload() creates a new navigation ID thta is set as pending and FrameLoader::reload() is called, but it returns early because the URL is empty. Because of this createDocumentLoader is not called and the pending navigation not reset.
 6. webkit.org request finishes because the reload did nothing, so it wasn't cancelled. 
 7. Reload is called again and WebPage::reload() asserts because it still has a pending navigation from previous reload.

This might be a more general problem, all other load methods in WebPage expect that the pending navigation is reset after doing the load, but FrameLoader can return early before creating the document loader in other cases too, no only in case of reload. 

There are different ways to solve this:

 - We could simply check after calling reload() in WebPage::reload() is the pending navigation has been reset or not, and reset it, assuming that the reload simply didn't happen in such case.

 - I don't know if the early return in FrameLoader::reload() when the url is empty is correct. The comment says that's expected to happen when a window is created by javascript, but this is not the case. That code has always been there, though (since 2005). Removing the early return fixes the crash.

 - We could add another callback to the client to notify the WebPage from the frame loader when a load or reload request is ignored. This might be a more general solution if this is a problem for other load methods.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180226/6a8680c9/attachment.html>