Bug 110655 – Add willGoToHistoryItem on WebKit(1) Mac platform

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit API

[Alice Liu]

WebKit(1) Mac has shouldGoToHistoryItem but it doesn't have willGoToHistoryItem.  I'd like to add it.

[Alice Liu]

Created attachment 189855 [details]
patch

Comment on attachment 189855 [details]
patch

Is there any case where returning YES from -webView:shouldGoToHistoryItem: doesn’t mean that the WebView will go to that item? Can’t the delegate do whatever it could do in -webView:wellGoToHistoryItem: in its implementation of -webView:shouldGoToHistoryItem: just before returning YES?

[Alice Liu]

(In reply to comment #2)
> (From update of attachment 189855 [details])
> Is there any case where returning YES from -webView:shouldGoToHistoryItem: doesn’t mean that the WebView will go to that item? Can’t the delegate do whatever it could do in -webView:wellGoToHistoryItem: in its implementation of -webView:shouldGoToHistoryItem: just before returning YES?

In WebKit/mac/WebCoreSupport/WebFrameLoaderClient.mm, as currently written in the patch, there is no situation in which an affirmative "should-" doesn't also result in a subsequent call to "will-".  However, I don't necessary agree with the notion that simply because it doesn't means that we're better off combining the purpose of both into just "should-".  As I see it, the purpose of "should-doSomething" is to let the client have a say in whether doSomething should occur.  And naturally "will-doSomething" is to let the client know about forthcoming action.  Please see <a href="http://trac.webkit.org/browser/trunk/Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp#L957">WebKit2 WebFrameLoaderClient.cpp</a> for a similar example.

(In reply to comment #3)
> (In reply to comment #2)
> > (From update of attachment 189855 [details] [details])
> > Is there any case where returning YES from -webView:shouldGoToHistoryItem: doesn’t mean that the WebView will go to that item? Can’t the delegate do whatever it could do in -webView:wellGoToHistoryItem: in its implementation of -webView:shouldGoToHistoryItem: just before returning YES?
> 
> In WebKit/mac/WebCoreSupport/WebFrameLoaderClient.mm, as currently written in the patch, there is no situation in which an affirmative "should-" doesn't also result in a subsequent call to "will-".  However, I don't necessary agree with the notion that simply because it doesn't means that we're better off combining the purpose of both into just "should-".  As I see it, the purpose of "should-doSomething" is to let the client have a say in whether doSomething should occur.  And naturally "will-doSomething" is to let the client know about forthcoming action.

Indeed. But in Cocoa API, when a “should” exists, a “will” is normally not necessary. See for example the NSTableViewDelegate method -tableView:shouldReorderColumn:toColumn: or the NSTextView delegate method -textView:shouldChangeTextInRange:replacementString:.

> Please see <a href="http://trac.webkit.org/browser/trunk/Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp#L957">WebKit2 WebFrameLoaderClient.cpp</a> for a similar example.

That’s quite different. The “should” call goes to the injected bundle client, whereas the “will” call goes to some client in the UI process. In your patch, you are sending the two messages to the same delegate.