Fixed element collapsing in Safari

safari/ext/content.js

Index: safari/ext/content.js
===================================================================
--- a/safari/ext/content.js
+++ b/safari/ext/content.js
@@ -279,6 +279,9 @@
 
   /* Web request blocking */
 
+  var errorEvent = document.createEvent("Event");
+  errorEvent.initEvent("error");
+
   document.addEventListener("beforeload", function(event)
   {
     var type;
@@ -318,7 +321,14 @@
         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);