InformAction Forums

Also, until a restart it keeps happening on other sites with facebook like iframe, where the url is different (search string).

Initially it seemed that if you start with iframes forbidden that you would never see the abe alert, but that's not the case, I started seeing them.

Sorry for the confusing explanation: when I described it as an history/cache issue affecting frames, I meant that Gecko "remembers" (or caches) the frame structures for history-based navigation, and when it rebuilds it the requests are not seen as subdocuments, but as documents.
However I'm gonna check closer to see if there's any other non obvious side-effect.
One work-around for the immediate issue, though, is probably avoiding notifications for INCLUSION matches (opposite to SUB and "regular" methods which load documents).

Giorgio Maone wrote:requests are not seen as subdocuments, but as documents.

I still don't quite understand. When iframes are blocked there shouldn't be any requests for abe to block. And what about abe alerts on different pages and sites, their frame structure has not been cached?

al_9x wrote:And what about abe alerts on different pages and sites, their frame structure has not been cached?

I missed that bit. Could you assemble a reproducible test case?

NVM. I managed to both reproduce and find the explanation.
Frame blocking checks, for a number of reasons (one of which is delivering a mostly uniform blocking behavior for frames, notwithstanding the aforementioned history-related issues), are deferred to a later stage than the early nsIContentPolicy::shouldLoad(), after ABE but still before the request hits the network.
Nothing to be worried about and, again, a good reason to explicitly bypass notifications for ABE INCLUSION matches.

Giorgio Maone wrote:

al_9x wrote:And what about abe alerts on different pages and sites, their frame structure has not been cached?

I missed that bit. Could you assemble a reproducible test case?

1. new profile + .79
2. add this rule

   Code: Select all

   Site .facebook.com .fbcdn.net
   Accept from .facebook.com .fbcdn.net
   Deny INC
   

3. go here
4. since iframes are not blocked, you get a legitimate abe block and alert
5. close the alert, go to about:blank, clear history (everything), block iframes (on trusted)
6. go to the same page
7. still get the abe alert, in theory, there is no request for abe to block
8. go to a different site with a facebook iframe
9. you should get the abe alert
10. if you clear everything and restart ("block iframes" already set), you should not see abe alerts on either site, although, as I mentioned, sometimes they start.

Giorgio Maone wrote:a good reason to explicitly bypass notifications for ABE INCLUSION matches.

I think someone requested making notifications configurable in the abe rule, what do you think about that?

Also, according to your explanation, shouldn't the behavior be consistent, i.e. always get the abe alert?

al_9x wrote:Also, according to your explanation, shouldn't the behavior be consistent, i.e. always get the abe alert?

No, not necessarily.
It depends whether DNS info about the frame's host is currently cached or not (if it's not cached, ABE checks are deferred until DNS resolution while frame blocking happens immediately).

al_9x wrote: I think someone requested making notifications configurable in the abe rule, what do you think about that?

It can be useful to have, but low priority.

Giorgio Maone wrote:if it's not cached, ABE checks are deferred until DNS resolution while frame blocking happens immediately

Thanks for the clarification, that explains why I started seeing them, the abe alert can be triggered by opening facebook.com, thus caching dns, then reloading the page with the iframe.