Colloquy doesn’t render any chat content after <http://trac.webkit.org/changeset/191652>. It seems this app relies on the WebKit's old non-standard behavior.
rdar://problem/23381007
Created attachment 264749 [details] Patch
Created attachment 264754 [details] Patch
Comment on attachment 264754 [details] Patch Clearing flags on attachment: 264754 Committed r192016: <http://trac.webkit.org/changeset/192016>
All reviewed patches have been landed. Closing bug.
Am I correct in understanding that this patch restores the old behavior but there are no test cases covering it any more? That doesn’t seem so great if so. Should we pursue a linked on or after solution to preserve the old behavior only for old apps? Then we could remove it eventually?
(In reply to comment #6) > Am I correct in understanding that this patch restores the old behavior but > there are no test cases covering it any more? That doesn’t seem so great if > so. fast/frames/iframe-no-name.html was rebaselined and covers the old behavior. > Should we pursue a linked on or after solution to preserve the old behavior > only for old apps? Then we could remove it eventually? I think it would be great but I am not sure how we would go about it. How would I detect old apps?
(In reply to comment #7) > (In reply to comment #6) > > Should we pursue a linked on or after solution to preserve the old behavior > > only for old apps? Then we could remove it eventually? > > I think it would be great but I am not sure how we would go about it. How > would I detect old apps? To find this being done for WebKit 1 on Mac, grep for LinkedOn. You can find a set of these done through Settings in WebView.mm but there are other variants as well. To find this being done for WebKit 2 on iOS, grep for dyld_get_program_dk_version. There’s one example of this in WKWebView.mm. I couldn’t quickly find any examples yet of doing this for WebKit 2 for Mac. Anders and Sam are among the many people who know more about the possibilities, I think.