Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Brief: images in feeds are blocked #29

Closed
msxfm opened this issue Jul 7, 2014 · 10 comments
Closed

Brief: images in feeds are blocked #29

msxfm opened this issue Jul 7, 2014 · 10 comments

Comments

@msxfm
Copy link

msxfm commented Jul 7, 2014

Issue by jsamuel
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#29


imported trac ticket
created: 2009-08-08 19:21:01
reporter: justin

Aus has reported that when using RequestPolicy, all images displayed by the Brief rss reader extension are blocked.

@msxfm
Copy link
Author

msxfm commented Jul 7, 2014

Comment by jsamuel
Thursday Dec 22, 2011 at 18:46 GMT


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.

@msxfm
Copy link
Author

msxfm commented Jul 7, 2014

Comment by jsamuel
Thursday Dec 22, 2011 at 18:46 GMT


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?

@msxfm
Copy link
Author

msxfm commented Jul 7, 2014

Comment by jsamuel
Thursday Dec 22, 2011 at 18:46 GMT


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.

@msxfm
Copy link
Author

msxfm commented Jul 7, 2014

Comment by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT


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.

@msxfm
Copy link
Author

msxfm commented Jul 7, 2014

Comment by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT


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.

@msxfm
Copy link
Author

msxfm commented Jul 7, 2014

Comment by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT


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.

@genodeftest
Copy link
Contributor

This is not applicable any more. With 1.0 beta8.2 images in brief are not blocked.

@nodiscc
Copy link
Contributor

nodiscc commented Jan 30, 2015

@genodeftest Are you using RequestPolicy in Default: block policy?

@genodeftest
Copy link
Contributor

Yes, I am.

@nodiscc
Copy link
Contributor

nodiscc commented Jan 30, 2015

Thanks! This can be closed.

@nodiscc nodiscc closed this as completed Jan 30, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants