Bug 181010
| Summary: | A KVO change notification for WKWebView's _pinnedState property is not generated when a load of custom content is committed | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jeff Miller <jeffm> |
| Component: | WebKit API | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | jeffm, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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.