Neuter WKFrameIsFrameSet() / WKPageGetFrameSetLargestFrame() C API. This is only SPI and is only used for slightly different printing behavior in Safari. Framesets are no longer supported in HTML5 and are now super rare. Support for this C API adds quite a bit of code complexity and crashes such as <rdar://problem/60322282>, it just does not seem worse it anymore.
Created attachment 399181 [details] Patch
Comment on attachment 399181 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=399181&action=review > Source/WebKit/UIProcess/API/C/WKFrame.cpp:125 > bool WKFrameIsFrameSet(WKFrameRef frameRef) Is there an "SPI deprecation" thing to be done? > Source/WebKit/UIProcess/API/C/WKPage.cpp:393 > - return toAPI(toImpl(pageRef)->frameSetLargestFrame()); > + return nullptr; Would it be safer to return the main frame rather than null?
Comment on attachment 399181 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=399181&action=review >> Source/WebKit/UIProcess/API/C/WKFrame.cpp:125 >> bool WKFrameIsFrameSet(WKFrameRef frameRef) > > Is there an "SPI deprecation" thing to be done? WK_C_API_DEPRECATED
Comment on attachment 399181 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=399181&action=review >> Source/WebKit/UIProcess/API/C/WKPage.cpp:393 >> + return nullptr; > > Would it be safer to return the main frame rather than null? If we remove the use of this function (and please mention the radar where you do such) then we only need to keep the C functions in the binary so SafariForWebKitDevelopment can start with open source builds of WebKit, which is probably NBD in this case.
Comment on attachment 399181 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=399181&action=review >>> Source/WebKit/UIProcess/API/C/WKFrame.cpp:125 >>> bool WKFrameIsFrameSet(WKFrameRef frameRef) >> >> Is there an "SPI deprecation" thing to be done? > > WK_C_API_DEPRECATED Will add. >>> Source/WebKit/UIProcess/API/C/WKPage.cpp:393 >>> + return nullptr; >> >> Would it be safer to return the main frame rather than null? > > If we remove the use of this function (and please mention the radar where you do such) then we only need to keep the C functions in the binary so SafariForWebKitDevelopment can start with open source builds of WebKit, which is probably NBD in this case. Yes, I will follow-up and drop corresponding code from client. Returning nullptr here is safe. This method could always return null and would only return non-null when there is a frameset. Returning the main frame would be a behavior change and may actually cause a behavior change in client too. I have checked that the only client of this SPI properly null-checks the result.
Created attachment 399185 [details] Patch
Committed r261586: <https://trac.webkit.org/changeset/261586> All reviewed patches have been landed. Closing bug and clearing flags on attachment 399185 [details].
<rdar://problem/63159822>