Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#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):

Description

Environment

OSX 10.8.5
Safari 6.2
Adblock Plus 1.8.12.1406

and

OSX 10.10.1
Safari 8.0
Adblock Plus 1.8.12.1406

How to reproduce

  1. Go to https://adblockplus.org
  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 www.youtube-nocookie.com".

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

Change History (4)

comment:1 Changed 5 years ago 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 5 years ago 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 5 years ago 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 5 years ago by sebastian (previous) (diff)

comment:4 Changed 5 years ago 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 chrome.windows.create() 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.

Note: See TracTickets for help on using tickets.