<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Content Blocker - blocked requests should not seem successful to requester"
   href="https://bugs.webkit.org/show_bug.cgi?id=151649">151649</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Content Blocker - blocked requests should not seem successful to requester
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>WebKit
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>WebKit Nightly Build
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>Normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P2
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>WebCore Misc.
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>webkit-unassigned&#64;lists.webkit.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>am&#64;adguard.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>There is an issue with the way content blockers present blocked requests to the requesters.

Usually (e.g. for all other browsers) when request is blocked by add-on or extension it looks like an error to the page code. For instance, &quot;onerror&quot; is called for XMLHttpRequest and &quot;element.onerror&quot; callback is called for the DOM element if it's load is blocked by the ad blocker.

This is a common behavior and it's handled by web developers.

In case of Safari content blocker &quot;onerror&quot; event is not raised and it may seem that request is successful while it is not.

Here is an example.

This is a rule blocking access to visualwebsiteoptimizer.com domain.
This domain is a known tracker so you can see this rule in all &quot;privacy&quot; related filter lists like EasyPrivacy and such.
[
    {
        &quot;trigger&quot;: {
            &quot;url-filter&quot;: &quot;^https?://[^.]+\\.?visualwebsiteoptimizer\\.com[/:&amp;?]?&quot;,
            &quot;load-type&quot;: [
                &quot;third-party&quot;
            ]
        },
        &quot;action&quot;: {
            &quot;type&quot;: &quot;block&quot;
        }
    }
]

But it can't be used in Safari because the &quot;silent&quot; blocking breaks entire website which use visualwebsiteoptimizer.com. Examples of such websites: 
<a href="http://info.singtel.com">http://info.singtel.com</a>
<a href="http://www.harveynorman.com.au">http://www.harveynorman.com.au</a>

Here is a code used by them:
<a href="http://pastebin.com/awYa9s95">http://pastebin.com/awYa9s95</a>

As you can see they handle &quot;onerror&quot; callback, but it's not fired in Safari so the &quot;body&quot; element remains hidden.

Btw, this issue also causes significant delays when ads are blocked on Youtube. They also are waiting for &quot;onerror&quot; callback to fire, but as it is not fired, video does not start until &quot;ontimeout&quot; is fired.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>