[webkit-reviews] review canceled: [Bug 188245] [Cocoa] More tweaks and refactoring to prepare for ARC : [Attachment 346605] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Aug 6 09:01:23 PDT 2018


Darin Adler <darin at apple.com> has canceled Darin Adler <darin at apple.com>'s
request for review:
Bug 188245: [Cocoa] More tweaks and refactoring to prepare for ARC
https://bugs.webkit.org/show_bug.cgi?id=188245

Attachment 346605: Patch

https://bugs.webkit.org/attachment.cgi?id=346605&action=review




--- Comment #31 from Darin Adler <darin at apple.com> ---
Comment on attachment 346605
  --> https://bugs.webkit.org/attachment.cgi?id=346605
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=346605&action=review

Since the Tools part is completely separable from the non-Tools part, it’s OK
if I just get a review on one or the other. I can land that half and open
another bug for the other half.

>> Source/WTF/wtf/spi/cocoa/FoundationSPI.h:47
>> +WTF_EXTERN_C_END
> 
> Not new to this patch, but I’d have named this header objcSPI.h (like the one
in WebKit).

OK, I’ll rename and upload a new version of the patch.

>> Source/WebKitLegacy/mac/History/WebHistory.mm:647
>> +	    static NSData *emptyHistoryData = [[NSData alloc]
initWithBytes:nullptr length:0];
> 
> Can also use -init.

Will do.

>> Source/WebKitLegacy/mac/Misc/WebNSDataExtras.mm:85
>> +		result =
CFBridgingRelease(CFStringCreateWithCharactersNoCopy(nullptr, uniCharPtr, len,
nullptr));
> 
> I’d replace the first nullptr with kCFAllocatorDefault like in some of the
above code, but I don’t think there’s a style guideline either way.

Sure, OK, why not?

>> Source/WebKitLegacy/mac/Misc/WebNSDataExtras.mm:91
>> +	return result;
> 
> This introduces a slight change in behavior under manual retain/release. Not
a problem since the only caller is in this file and doesn’t deallocate the
receiver right after calling this method.

I think I’ll leave it like this.

Otherwise, the alternative I would probably choose would be a copy/autorelease
in the "result = self" line above. Even under ARC I could imagine returning a
copy rather than self. But I don’t want to risk a small performance regression
without a compelling reason.

>> Source/WebKitLegacy/mac/WebView/WebImmediateActionController.mm:148
>> +	Frame* coreFrame = [_webView _mainCoreFrame];
> 
> Seems like this won’t do the right thing if the selection or focus is in a
subframe. Unless WebCore hit-testing now traverses frames? Even then, it seems
wrong.

I see. I was under the incorrect impression that the frame was only to work
with the immediate action stage, like the other call sites. But I see now that
it’s also used for hit testing.

I will restore the old code for the hit testing purposes.


More information about the webkit-reviews mailing list