imported trac comment
created: 2009-10-04 17:40:55
author: Plox

Just in case it helps, I use both yet worked around this issue by allowing "brief-content" as an origin.

imported trac comment
created: 2010-02-11 13:07:06
author: GµårÐïåñ

I do not experience any issue on this and just noticed that it shows up as an incompatible extension on the menu. Could you be blocking these by the act of Adblock or NoScript?

imported trac comment
created: 2010-02-15 15:50:38
author: Plox

Don't think so, I can reproduce it with NoScript disabled (and I don't use ABP anyway).

I just removed "brief-content" from the allowed origins list, which prevented the images within all rss feeds from loading. Re-adding it fixes the issue.

imported trac comment
created: 2010-02-16 11:21:21
author: GµårÐïåñ

Ok, then you seem to have done everything right, let me play around and experiment with my configurations and see if I can figure out why it works for me without needing to do that but it doesn't for you. Maybe we can figure out a fix for you and it might not even be RP or it might be a part of RP that is being changed or overridden by another extension that is making it work. I will keep you posted if I find anything that might help.

imported trac comment
created: 2011-01-07 16:29:11
author: justin

Partially fixed in r387. This change should allow most direct requests made from Brief's feed view. However, there are still some requests that get blocked, specifically any content Brief adds to the feed view that in turn initiates a cross-site request. I tried out this change on about 30 feeds (from some random OPML file found with a google search for filetype:opml) and only a few of the feeds had any blocked content.

I've tested this change on Brief 1.2.5 and Brief 1.5b3.

I'm going to leave this ticket open as the problem isn't fundamentally solved. I'm not entirely sure what the right solution is, either. That is, I'm not sure any arbitrary series of requests should be allowed. Ideally one would have the ability to whitelist blocked requests using the menu, but this is a level of complication beyond what we can handle right now. Part of what makes that hard right now is that we don't see and/or don't track certain privileged requests, so we don't have information that can link the blocked requests back to the top-level chrome: URL of the Brief tab. Therein lies the fundamental issue at the moment: we don't seem to have any way of knowing through the nsIContentPolicy::shouldLoad API that these requests originate from Brief and we aren't tracking enough other information to deduce that ourselves.

imported trac comment
created: 2011-01-07 16:37:25
author: justin

I take back that last part I said: I think there may be enough information to track any requests back to the origin resource://brief-content/feedview-template.html, though not to the origin chrome://brief/content/brief.xul which is the URL of the Brief tab/document (which is the URL we have to trace back to in order for the RP menu to be useful for whitelisting). That leaves a few possibilities of how to proceed.