Bug 143414 – [Content Filtering] Tell the filter about requests and redirects

• Component: New Bugs
• Status: RESOLVED FIXED

[Andy Estes]

[Content Filtering] Tell the filter about requests and redirects

[Andy Estes]

rdar://problem/19239549

[Andy Estes]

Created attachment 250153 [details]
Patch

[WebKit Commit Bot]

Attachment 250153 [details] did not pass style-queue:


ERROR: Source/WebCore/platform/cocoa/NetworkExtensionContentFilter.mm:85:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Total errors found: 1 in 30 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Darin Adler]

Comment on attachment 250153 [details]
Patch

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

> Source/WebCore/loader/DocumentLoader.cpp:541
> +        ASSERT(!newRequest.isNull());

Why do we assert this rather than handling this and having it cause cancellation/failure?

[Andy Estes]

Comment on attachment 250153 [details]
Patch

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

>> Source/WebCore/loader/DocumentLoader.cpp:541
>> +        ASSERT(!newRequest.isNull());
> 
> Why do we assert this rather than handling this and having it cause cancellation/failure?

ContentFilter::willSendRequest() blocks by scheduling a substitute data load which cancels the in-progress load, but now that you mention it, it would make more sense to actually null out newRequest and cancel immediately. I'll do that instead.

[Andy Estes]

Committed r182369: <http://trac.webkit.org/changeset/182369>

[Myles C. Maxfield]

This made one test fail consistently on Win. https://build.webkit.org/builders/Apple%20Win%207%20Release%20(Tests)?numbuilds=50

[Andy Estes]

https://bugs.webkit.org/show_bug.cgi?id=143460 tracks the Windows failure.