Bug 150861

Summary: Regression(r191652): Colloquy doesn’t render any chat content
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: DOMAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: andersca, commit-queue, darin, esprehn+autocc, gyuyoung.kim, koivisto, mitz, rniwa, sam, webkit-bug-importer
Priority: P2 Keywords: InRadar, WebExposed
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 150565    
Attachments:
Description Flags
Patch
none
Patch none

Chris Dumez
Reported 2015-11-03 15:39:24 PST
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.
Attachments
Patch (2.46 KB, patch)
2015-11-03 16:13 PST, Chris Dumez 		no flags
DetailsFormatted DiffDiff
Patch (6.23 KB, patch)
2015-11-03 16:41 PST, Chris Dumez 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Chris Dumez
Comment 1 2015-11-03 15:39:41 PST
rdar://problem/23381007
Chris Dumez
Comment 2 2015-11-03 16:13:42 PST
Created attachment 264749 [details] Patch
Chris Dumez
Comment 3 2015-11-03 16:41:04 PST
Created attachment 264754 [details] Patch
WebKit Commit Bot
Comment 4 2015-11-04 00:11:03 PST
Comment on attachment 264754 [details] Patch Clearing flags on attachment: 264754 Committed r192016: <http://trac.webkit.org/changeset/192016>
WebKit Commit Bot
Comment 5 2015-11-04 00:11:09 PST
All reviewed patches have been landed. Closing bug.
Darin Adler
Comment 6 2015-11-04 08:46:37 PST
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?
Chris Dumez
Comment 7 2015-11-04 09:38:32 PST
(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?
Darin Adler
Comment 8 2015-11-04 09:46:58 PST
(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.
Note You need to log in before you can comment on or make changes to this bug.