Bug 181010 – A KVO change notification for WKWebView's _pinnedState property is not generated when a load of custom content is committed

• Status: NEW
• Component: WebKit API

[Jeff Miller]

WKWebView's _pinnedState property is not observable. I don't see any code in WebKit that would notify Cocoa when a page's m_mainFrameIsPinnedToLeftSide/m_mainFrameIsPinnedToRightSide/m_mainFrameIsPinnedToTopSide/m_mainFrameIsPinnedToBottomSide ivar is changed.

[Radar WebKit Bug Importer]

<rdar://problem/36144485>

[Jeff Miller]

Hmm, there's code in PageClientImpl::pinnedStateDidChange() that should be doing this when m_pageClient.pinnedStateDidChange() is called. Although it looks like we only call this in WebPageProxy::didChangeScrollOffsetPinningForMainFrame(), but not in WebPageProxy::didCommitLoadForFrame(), and we call m_uiClient->pinnedStateDidChange() in both places.

[Jeff Miller]

The missing calls in WebPageProxy::didCommitLoadForFrame() appear to be the issue.

[Jeff Miller]

I misunderstood when the _pinnedState property changes. KVO works correctly when the page is scrolled, which is the most common case. I didn't realize that scrolling was necessary to generate the property change.

There's still a bug in WebPageProxy::didCommitLoadForFrame() where we aren't calling m_pageClient.pinnedStateWillChange()/m_pageClient.pinnedStateDidChange(), but only when the main frame has a custom content provider, which isn't a common scenario. I assume viewing a PDF would be an example of a custom content provider, but I haven't confirmed that.

The fix is straightforward, but I need to also write a test. I'm re-titling the bug to capture the actual issue.

[Jeff Miller]

I misunderstood when the _pinnedState property changes. KVO works correctly when the page is scrolled, which is the most common case. I didn't realize that scrolling was necessary to generate the property change.

There's still a bug in WebPageProxy::didCommitLoadForFrame() where we aren't calling m_pageClient.pinnedStateWillChange()/m_pageClient.pinnedStateDidChange(), but only when the main frame has a custom content provider, which isn't a common scenario. I assume viewing a PDF would be an example of a custom content provider, but I haven't confirmed that.

The fix is straightforward, but I need to also write a test. I'm re-titling the bug to capture the actual issue.

[Jeff Miller]

Tim Horton tells me that when the main frame is displaying a PDF document on the Mac it's a plug-in document, which isn't a custom content view. The only custom content provider he knows about is WKPDFView on iOS, so this would only be an issue there.