Opened on 03/27/2015 at 04:18:03 PM

Closed on 03/28/2015 at 03:34:40 PM

Last modified on 03/28/2015 at 03:36:46 PM

#2223 closed defect (rejected)

Block element dialog blocked on websites using Content Security Policy on Safari

Reported by: greiner Assignee:
Priority: Unknown Milestone:
Module: Platform Keywords:
Cc: sebastian Blocked By:
Blocking: Platform: Safari
Ready: no Confidential: no
Tester: Verified working: no
Review URL(s):



OSX 10.8.5
Safari 6.2
Adblock Plus


OSX 10.10.1
Safari 8.0
Adblock Plus

How to reproduce

  1. Go to
  2. Click on the Adblock Plus icon and select "Block element" in the popup
  3. Click on any element on the page

Observed behaviour

  • Background color of selected element changes from yellow to red
  • Adblock Plus dialog is not shown
  • JavaScript console contains the following error message: Refused to frame 'safari-extension://org.adblockplussafari-GRYYZR985A/7b32a132/block.html' because it violates the following Content Security Policy directive: "frame-src".

Expected behaviour

  • Background color of selected element changes from yellow to red
  • Adblock Plus dialog is shown
  • JavaScript console does not contain error messages regarding the Safari extension

Attachments (0)

Change History (4)

comment:1 Changed on 03/27/2015 at 04:55:01 PM by sebastian

It doesn't seem to be possible to force Safari to ignore the Content Security Policy to load resources from your extension. So the only way to achieve the expected behavior would be to not use resources at all here, and construct the dialog with pure JavaScript.

Not a trivial task, and probably not worth the effort for Safari, but on the other hand this would allow us to get rid of web-accessible resources on Chrome as well.

comment:2 Changed on 03/27/2015 at 05:00:53 PM by greiner

Constructing the dialog in the context of the page would open up an entirely new attack vector. Therefore I was thinking more of something along the lines of opening it as a popup window or, if necesssary, as a new tab to keep both environments strictly isolated. Not sure how practical that'd turn out to be, though.

comment:3 Changed on 03/27/2015 at 05:27:44 PM by sebastian

That's true. I kinda like the idea to use a popup on Safari for the "Block Element" dialog. I think we can even hide the address bar there. However, IMO on Chrome the UX is better with the dialog injected into the page. Though, using a popup would also have some advantages there, like less interference with the web page and eliminating web accessible resources. Also I'm not sure if a solution where we use a popup on one platform and an iframe on another will be maintainable. Those approaches require quite different code paths.

Last edited on 03/28/2015 at 03:36:46 PM by sebastian

comment:4 Changed on 03/28/2015 at 03:34:40 PM by sebastian

  • Resolution set to rejected
  • Status changed from new to closed

I looked a little more into using a popup here. On Chrome, this seems to be a well feasible option. Popups created by a Chrome extension aren't matter to built-in popup blocking. And if you use there won't even be an address bar. On Safari however, you can only create popups in response to user gestures, which might be a problem here, since we currently message the background page first to retrieve the filters. Also you cannot completely remove the address bar and popups always show up with a notable delay (a few seconds after clicking) on Safari.

So my conclusion is that there is nothing worth doing here to improve the behavior on Safari. However, for Chrome using a popup actually seems to be a good option to get rid of web-accessible resources, but this is an unrelated issue.

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
Note: See TracTickets for help on using tickets.