[Webkit-unassigned] [Bug 93680] Back/Forward list with error page

[bugzilla-daemon at webkit.org]

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





--- Comment #21 from Basavaraj Padmashali Sidda <basavaraj.ps at samsung.com>  2013-03-04 07:44:29 PST ---
(In reply to comment #20)
> Hi Brady,
> 
> This issue is seen in webkit2 code based and not in webkit and chrome, and here is explanation, 
> 
> About the issue: 
> 
> When load with substitute data, LoadHTMLString() is called with m_loadType is Back/Forward Type for a error page(unreachable URL in our case) in FrameLoader::Load(), the loadType is set to “Reload” if shouldReloadToHandleUnreachableURL() returns true,  Standard Type otherwise. 
> 
> shouldReloadToHandleUnreachableURL() return value depends on m_delegateIsHandlingProvisionalLoadError. 
> 
> On Webkit(single process) or  when an error page is loaded, m_delegateIsHandlingProvisionalLoadError is set to true. Then a call is made to 
> 
> Client’s  dispatchDidFailProvisionalLoad(). This method does a load with substitute data (LoadHTMLString). On  LoadHTMLString , shouldReloadToHandleUnreachableURL () is called. It returns true. As a result the loadType is set to “Reload” and duplication of history item of the error page is not seen on Back/Forward navigation.  Then m_delegateIsHandlingProvisionalLoadError is reset. See the code below:
> 
> m_delegateIsHandlingProvisionalLoadError = true;
> m_client->dispatchDidFailProvisionalLoad(error); -- sync call of LoadHTMLString() in webkit(single process)
> m_delegateIsHandlingProvisionalLoadError = false;
> 
> However on webkit2 :
> m_delegateIsHandlingProvisionalLoadError = true;
> m_client->dispatchDidFailProvisionalLoad(error); -- async call of LoadHTMLString() in webkit(single process)
> m_delegateIsHandlingProvisionalLoadError = false;
> 
> The call to client’s dispatchDidFailProvisionalLoad() is async. The m_delegateIsHandlingProvisionalLoadError is reset before LoadHTMLString is called from the client. Thus shouldReloadToHandleUnreachableURL() returns false instead of true.  As result a Back/Forward navigation is affected.
> 
> 
> Have 2 approaches to fix the issue. 
> 
> Approach 1
> Implementation of sendSync in client's dispatchDidFailProvisionalLoad(). However this may not be good approach, because this will stall the UI process.
> Call flow for the same is WebProcess -> UIProcess -> App -> UIProcess -> Webprocess. Also overwriting loadType to “Reload” on history navigation does not seem to be proper.
> 
> Approach2
> The proposed patch (https://bug-93680-attachments.webkit.org/attachment.cgi?id=188035). 
> In this, we just restore the loadType if it is back/forward type when loading substitute data during Back/Forward Navigation, instead of overwriting loadType to "reload" and loading as reload.

working on approach 2: Reverting existing overwriting of loadType to reload, and on top of it adding proposed patch so that added test case to pass in chrome also and make sure that all existing old test cases to pass ?

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