[Webkit-unassigned] [Bug 198298] REGRESSION (r245756) [Mac] 2 TestWebKitAPI.DownloadProgress* and TestWebKitAPI._WKDownload.DownloadMonitorCancel are flaky timeouts

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=198298

--- Comment #7 from David Quesada <david_quesada at apple.com> ---
(In reply to Alexey Proskuryakov from comment #6)
> Comment on attachment 370906 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=370906&action=review
> 
> > Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm:629
> > +                auto resumeDataReference = [resumeData isKindOfClass:[NSData class]] ? IPC::DataReference { static_cast<const uint8_t*>(resumeData.bytes), resumeData.length } : IPC::DataReference { };
> 
> Silently failing to use resumeData seems quite unfortunate.

I'm not sure I follow what you mean here. Are you referring to the case where resumeData is not an NSData?

> What are we losing today, and what will make resuming fail in the future?

I'm not aware of any cases where the resumeData will be non-nil, non-NSData (if that's what you mean by what we're "losing"). Though the type check a bit paranoid, I don't necessarily object to it since we're working with an untyped dictionary.

> We should at least assert that resumeData is one of the types known today.

Sure. I could add an ASSERT(!resumeData || [resumeData isKindOfClass:[NSData class]]) in this method, if that's what you mean.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190530/165f3a3b/attachment.html>