Fixed element collapsing in Safari

safari/ext/content.js

 /*
  * This file is part of Adblock Plus <http://adblockplus.org/>,
  * Copyright (C) 2006-2013 Eyeo GmbH
  *
  * Adblock Plus is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 3 as
  * published by the Free Software Foundation.
  *
  * Adblock Plus is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ skipping 261 matching lines @@
       if (objectInfo.isFunction)
         obj.prototype = this.getProperty(objectId, "prototype");
 
       return obj;
     }
   };
 
 
   /* Web request blocking */
 
+  var errorEvent = document.createEvent("Event");
+  errorEvent.initEvent("error");
+
   document.addEventListener("beforeload", function(event)
   {
     var type;
 
     switch(event.target.localName)
     {
       case "frame":
       case "iframe":
         type = "sub_rame";
         break;
@@ skipping 19 matching lines @@
 
     if (!safari.self.tab.canLoad(event, {
       type: "webRequest",
       payload: {
         url: event.url,
         type: type,
         documentUrl: document.location.href,
         isTopLevel: window == window.top
       }
     }))
+    {
       event.preventDefault();
+
+      // Safari doesn't dispatch an "error" event when preventing an element
+      // from loading by cancelling the "beforeload" event. So we have to
+      // dispatch it manually. Otherwise element collapsing wouldn't work.
+      event.target.dispatchEvent(errorEvent);

[Wladimir Palant, 2014/01/16 09:21:24]

a) Does Safari really allow dispatching the same event multiple times? That's
non-standard and would likely be a security issue.

b) We are expecting a load event for frames, not error.

c) Dispatching an event visible to the webpage really doesn't seem to be the
right solution (in addition to being wasteful). How about an ext.onBlocked
callback that will be called with a node that *might* have been blocked? This
can be implemented via load/error event listeners on Chrome and triggered
directly on Safari.

[Sebastian Noack, 2014/01/16 13:20:56]

Apparently it does. But if that is non-standard, I agree that we shouldn't do
that. I uploaded a new patchset that fixes that.
Also fixed.
Actually it is important that the event is visible to the webstie. Do you
remember the SiteCatalyst issue
(https://adblockplus.org/blog/links-not-working-on-a-website-you-can-fix-that)?
The solution you suggested there required to handle the "error" event for a
blocked resource. This wouldn't be possible if that event isn't dispatched to
the website.
I would prefer to keep the same behavior for Chrome and Safari. And while this
event would be what you would expect from an onBlocked event in Safari, since it
can be triggered by the code that does the actual blocking. On Chrome it would
be rather an aggregation of the "load" and "error" event.

+    }
   }, true);
 
 
   /* API */
 
   ext.backgroundPage = {
     sendMessage: function(message, responseCallback) {
       _sendMessage(
         message, responseCallback,
         safari.self.tab, safari.self,
         {
           documentUrl: document.location.href,
           isTopLevel: window == window.top
         }
       );
     },
     getWindow: function()
     {
       return proxy.getObject(0);
     }
   };
 
   ext.onMessage = new ContentMessageEventTarget();
 })();