Try lazier updates.
Created attachment 152385 [details] Patch
Created attachment 152398 [details] Patch
Comment on attachment 152398 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=152398&action=review > Tools/TestWebKitAPI/Tests/mac/SetAndUpdateCacheModel.mm:63 > + // On change, the cache model always take the highest value of any preference bound to a WebView. The implementation of _cacheModelChangedNotification will take a higher cache model even if the WebPreferences object that is changing is not bound to a WebView. Weird, but that is legacy behavior. You could update this comment.
Committed r122665: <http://trac.webkit.org/changeset/122665>
This patch broke builds: /Volumes/Data/slave/snowleopard-release/build/WebKitBuild/WebKit.build/Release/WebKit.build/Objects-normal/x86_64/WebPreferences.o /Volumes/Data/slave/snowleopard-release/build/Source/WebKit/mac/WebView/WebPreferences.mm:226:5:{226:5-226:46}: error: instance method '-_postCacheModelChangedNotification' not found (return type defaults to 'id') [-Werror,3] [self _postCacheModelChangedNotification]; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.
Sorry but I'm rolling out this patch since I don't know how to fix this build failure.
Re-opened since this is blocked by 91321
(In reply to comment #5) > This patch broke builds: > > /Volumes/Data/slave/snowleopard-release/build/WebKitBuild/WebKit.build/Release/WebKit.build/Objects-normal/x86_64/WebPreferences.o > /Volumes/Data/slave/snowleopard-release/build/Source/WebKit/mac/WebView/WebPreferences.mm:226:5:{226:5-226:46}: error: instance method '-_postCacheModelChangedNotification' not found (return type defaults to 'id') [-Werror,3] > [self _postCacheModelChangedNotification]; > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1 error generated. My guess is to fix this issue you probably just need to reorder (or forward declare) the method. WebPreferences.mm:226 calls the method which is defined later in the file. Newer compilers just get this right, but in older compilers the order matters.
(In reply to comment #6) > Sorry but I'm rolling out this patch since I don't know how to fix this build failure. Thank you for reverting. I went to bed before the bots went red. (In reply to comment #8) > My guess is to fix this issue you probably just need to reorder (or forward declare) the method. WebPreferences.mm:226 calls the method which is defined later in the file. Newer compilers just get this right, but in older compilers the order matters. Yep, that is why that worked locally. I'll fix that...
Created attachment 152435 [details] Patch
Committed r122675: <http://trac.webkit.org/changeset/122675>
<rdar://problem/11872809>