|RequestPolicy 1.0.0a7 released||Justin Samuel||4/16/12 11:19 AM|
RequestPolicy 1.0.0a7 has been released. This includes the following changes:
* Links from view-source pages now work.
|Re: RequestPolicy 1.0.0a7 released||aaaa||4/18/12 2:14 PM|
Some sort of 'blacklist' functionality would be nice, to hide items that appear often and need blocking. This would in many cases save user the trouble of manually searching through all 10+ analytics/advertising domains. Something like NoScript's Untrusted functionality.
|Re: RequestPolicy 1.0.0a7 released||Justin Samuel||4/18/12 2:24 PM|
It's likely that a future 1.x version grows an "ignored destinations"
feature. Basically, destinations that wouldn't turn the flag icon red
when blocked and maybe would be grouped together in the UI.
For purposes of clarity, this isn't a blacklist in our terminology.
For reference, the "untrusted"/"ignored" feature is good ol' ticket #1:
|Re: RequestPolicy 1.0.0a7 released||John Perdikis||4/20/12 10:35 AM|
Thank you Justin, you're building a great addon here.
Is there any way to allow all requests from a specific webpage (not domain) eg. when I read articles in google reader i have to allow images/videos etc from the originating website.
I suppose we can't allow requests from something like this: "https://www.google.com/reader/*", right?
|Re: RequestPolicy 1.0.0a7 released||Justin Samuel||4/20/12 11:10 AM|
On Fri, Apr 20, 2012 at 10:35 AM, John Perdikis wrote:
Thanks. Positive feedback is always appreciated.
> Is there any way to allow all requests from a specific webpage (not domain)
Having rules be able to include a path element (e.g. path prefix
In a few weeks I'll have a much better idea of how much time I'll have
|Re: RequestPolicy 1.0.0a7 released||Wacław Jacek||4/21/12 3:27 AM|
When I click a box next to a preference name, it checks the box, but when I switch to another tab of the preferences page and then back, it's back to default. How can I help find out what causes this?
|Re: RequestPolicy 1.0.0a7 released||61473||5/17/12 7:51 AM|
Thanks for pointing me to this dev build, Justin.
I have a number of ideas, comments and questions that came to mind while using the alpha build yesterday.
There, that's about it. I hope I wasn't being too harsh. ;)
|Re: RequestPolicy 1.0.0a7 released||Justin Samuel||5/17/12 2:20 PM|
On Sat, Apr 21, 2012 at 3:27 AM, Wacław Jacek wrote:(Sorry for the delayed response. Life is comically busy, as always.)
Is it possible you have scripts disabled in Firefox? The new
well as to save changed values.
|Re: RequestPolicy 1.0.0a7 released||Justin Samuel||5/17/12 3:09 PM|
On Thu, May 17, 2012 at 7:51 AM, 61473 wrote:Thanks for trying it out despite its alpha status.
The problem with this is that if a user has unsaved changes on the
currently open preferences tab, they would be lost if a new
preferences page is loaded there. At the moment this wouldn't be too
big of a risk because most preferences are being saved immediately
(that's why there's no save button). I do like the idea and I'll give
this some more thought.
That's a good idea, thanks.
I probably do need to tweak the colors a bit but I also intend them to
be pretty faint. In the coming months I'll try it out on more
I think there is also a bug which is causing the grey background to be
either too light or too dark on certain systems. I noticed that once
but haven't have time to look into it yet.
You're completely right about this. This is one of those things I
meant to have done before I released the first public alpha but I just
didn't want to wait any longer. I'll get to this some time this
The initial setup window is going to be very simple, though. It
probably won't give options for subscription management. The goal is
to get out of the user's way as quickly as possible. Maybe there will
be a button for "advanced setup" or something in a corner which will
tell the user about subscriptions and such.
It only applies to images. Placeholders for other blocked objects
could be useful but it's nearly impossible for me to justify spending
time on that. I might be able to revisit this some time after 1.x has
been released to all users, but I'm inclined to think this will only
happen with someone contributing a patch.
What's currently there was just a quick hack and it might change a
lot. But, yeah, it would make sense to put "allow/block" on the same
line. I don't know about "temporary".
I doubt I'll add more UI complexity to save having to uncheck those
boxes. If there ends up being dozens of checkboxes, I'd probably add
It's very likely I'll be adding more subscription-related preferences.
For example, users might want subscriptions but not want them
automatically updated. And there may end up being a global
enable/disable for subscriptions (rather than a way to disable each
Subscriptions will definitely be enabled by default, though. One of
the goals of 1.x is to make RequestPolicy as easy to use for the
majority of users (case in point: adding a "default allow" mode).
Awesome, I'm glad that's working as desired.
I doubt I'll add the ability to enter rules manually through the menu.
That seems like too much UI complexity which is only useful to a very
small number of users. I think a better long-term solution will be
user-maintained or community-maintained subscriptions. e.g. you could
maintain your own subscriptions and the first thing you do in a new
firefox profile with RP is add your own subscriptions.
Not a bad idea, but the time required to do that and the extra
complexity doesn't seem worth it at the moment. As you've noticed,
right now every possible enhancement runs through the "is this going
to help me get 1.0 launched?" filter. That's part of why the 0.5
branch is getting so little love: the only way I can make any progress
on 1.0 is to ignore everything but major bugs in 0.5. Similarly, the
only way I can make progress on getting 1.0 released is to ignore a
lot of things that would be nice but aren't critical.
It takes a lot of convincing for me to want to add additional visual
hints because these generally don't mean anything to most users. For
example, I've received a few requests over the years for additional
flag icon colors to represent different things. I generally dislike
all of those ideas. I want simpler UIs, not more complicated ones.
However, after 1.0 is launched I do intend to consider various
advanced menu options that are disabled by default. Maybe this can be
one of them.
Not too harsh at all. Hopefully my answers aren't, either.
Thanks for taking the time to provide feedback and suggestions.
|Re: RequestPolicy 1.0.0a7 released||61473||5/18/12 2:10 AM|
Hey, thanks for the reply.
Eh, I'm not sure we understood each other here. I'm not asking you to add a textbox, listbox or anything similar (where a user has to manually type in or edit the rules) to the icon menu. If your default policy is block then you will only be able to add items to a whitelist, but not the blacklist (and vice-versa). I'm asking you to add an option to the icon menu that will let users add requests to blacklist and/or whitelist regardless of the current default policy.
- Set your request policy to deny-by-default.
- Go to http://2020ok.com
- Click the request policy icon to bring up the menu.
- You will notice a number of requests being blocked on the left side of the menu. One of them will be "msn.com".
- Now I would like to add this "msn.com" to my blacklist. So I click it to bring up the submenu on the right part of the popup.
- I only see four items:
Allow requests from *.2020ok.com to *.msn.com
Temporarily allow requests from *.2020ok.com to *.msn.com
Allow requests to *.msn.com
Temporarily allow requests to *.msn.com
But there are no items in here to add these requests to a blocklist. I want the block-equivalents of these items to appear in the same menu. Currently if I want to permanently block the request I have to:
- Click the "Temporarily allow requests from *.2020ok.com to *.msn.com" option
- Click outside the menu to refresh the page
- Bringup the icon menu again. This time ksn.com will appear green. Click it.
- Choose the "Block all requests to *.msn.com" option
- Click outside the menu to refresh the page
I't a bit annoying having to take this detour.
> The current tab in the "Your Policy" page only lists the policies, but won't
It's no problem, I merely wanted to share a few ideas for features that might appear in the future.
> In the icon menu perhaps there should be some way to differ between items
Well I am an advanced user, so that might explain it. I do prefer to manage my own policies over subscriptions, so sometimes the menu gets clogged up with many blocked and many allower requests. I have to click on each one of them to find out whether there is a permanent rule already in place. I thought a way to distinguish between temporary and permanent rules in the left frame of the icon menu would be nice.
> There, that's about it. I hope I wasn't being too harsh. ;)
I came up with a bunch more suggestions yesterday while playing with the request log.
|Re: RequestPolicy 1.0.0a7 released||61473||5/18/12 3:03 PM|
I think I found a bug. Sometimes the blocked images are replaced by a placeholder despite that the destination where the images are located is allowed. I'm using the deny-by-default policy and subscriptions under the "Usability" group are disabled. The "Browser" group is fully enabled. Requests to the same domain are allowed.
I noticed this happening multiple times on various websites, but the most recent one was http://www.trillian.im. When I restart firefox, the bug is gone and I am unable to reproduce it. Here's what happened: I was browsing a lot of websited and ended up on the trillian website. Having the deny-by-default policy, I noticed that almost all images are blocked (saw placeholders). So I clicked the icon menu and tried to allow the cachefly.net domain where the images are located. Upon opening the icon menu, I noticed that the cachefly.net domain was listed under the "Mixed destinations" group and its color was orange. I have no idea how it managed to get there, but clicking on it opened all possible menu items. If I recall correctly there were 8 total... (Temporary) Allow requests from trillian to cachefly, (Temporary) Allow requests to cachefly, and the 4 block equivalents. Clicking on either had no effect. Despite having fully allowed the domain, it still appeared orange under mixed destinations, and the images didn't load even after multiple page reloads.
After restarting FF the cachefly.net domain now appears red under blocked destinations. When I allow requests to cachefly, the images load properly.
|Re: RequestPolicy 1.0.0a7 released||Wacław Jacek||5/19/12 5:06 AM|
Justin Samuel wrote:
> Is it possible you have scripts disabled in Firefox? The newI can hardly tell at this point. I have started using vanilla Firefox (I
was using GNU IceCat earlier) and I think it's working now.
|Re: RequestPolicy 1.0.0a7 released||61473||5/23/12 8:16 AM|
Another bug. Magnet links do not work properly (Firefox 12.0, Arch linux, requestpolicy 1.0.0a7, block by default policy). Go to website like http://thepiratebay.se/torrent/7218806/Ubuntu-12.04-desktop-i386.iso and click on the magnet link (GET THIS TORRENT). The link does not get passed to the appropriate download application. I found out that you can still pass on the link by triple-clicking it quickly.
With requestpolicy addon disabled, magnet links work properly.