[Firefox] Problem with “element hiding” filters

[sn260591]

When open any page with a picture on deviantart.com for the first time "Download" button in the upper right corner is not working. The problem disappears if reload the page or off "element hiding" filters, but returns again after restarting the browser.
Example: http://skrainev.deviantart.com/art/Rendezvous-with-a-comet-203810612

[gorhill]

There is an invisible iframe over the button. The network request for that iframe is blocked. uBlock expects that the iframe will fire an event so that uBlock can look into whether it needs to be virtually removed, however it looks like no event is fired (unlike on Chromium), and thus the invisible iframe is there covering the button.

It doesn't help that I have no clue on how to debug content scripts on Firefox.

[gorhill]

Maybe related to: https://bugzilla.mozilla.org/show_bug.cgi?id=444165

[gorhill]

For now I created a cosmetic filter to address this issue: deviantart.com##.dp-ad-chrome.dp-ad-visible.

But the real issue is that it appears no event is fired for when the content of a frame does not load. Need to investigate more.

[tophf]

I have no clue on how to debug content scripts on Firefox.

Maybe this is the answer: Firefox Add-on Debugger.

[gorhill]

Yes, I figured since long that part. I am talking about content scripts injected in the web page.

[gorhill]

@Deathamns I would like to have some help here.

From my limited understanding:

Apparently shouldLoad has a view on the iframe tag which is being processed. However the decision to block or not is done within httpObserver.handleRequest , which has no knowledge of the iframe object to which belong the URL being filtered.

So I am wondering if there is a way, any way for shouldLoad to be aware of the result of the filtering -- at least when the resource is being blocked, at least for iframe, and thus being able to fire a synthetic error event to the iframe... ?

[Deathamns]

@gorhill Yes, you can receive responses with synchronous messaging as well, however...

[gorhill]

synchronous messaging

It doesn't have to be synchronous, asynchronous is fine, the important part being that the uBlock's content script receives the error event it expects when the iframe isn't loaded because it was blocked.

[Deathamns]

The solution with async messaging would be no different if you query all the iframes, and check their URL.

[sn260591]

With adblock plus, this problem is missing. Maybe, the solution can be found in abp source code.

[Sollace]

I was linked here from the fix line in uBlock's filter:

# https://github.com/chrisaljoudi/uBlock/issues/618
deviantart.com##.dp-ad-chrome.dp-ad-visible

This will not always work because of deviantart randomising the letters in place of the 'dp' prefix.

Here is an excerpt from my own ad blocking userstyle of some selectors that correctly target the iframes.

*[class*=-ad-chrome],
*[class*=-ad-container],
*[class*=-ad-frontpage-banner],

You can probably get away with just changing the static filter to:

deviantart.com##[class*="-ad-chrome"]