* Links from view-source pages now work.
* When the menu is opened through the keyboard shortcut, it is placed
better when the Firefox window is not maximized.
Justin
For purposes of clarity, this isn't a blacklist in our terminology.
RequestPolicy 1.0 supports blacklists in terms of "block" (deny) rules
that are mostly useful when using the default-allow policy. So,
RequestPolicy 1.0 has both whitelists and blacklists but these aren't
related to ignoring indications of blocked requests.
For reference, the "untrusted"/"ignored" feature is good ol' ticket #1:
https://github.com/RequestPolicy/requestpolicy/issues/1
Justin
> --
> You received this message because you are subscribed to the Google Groups
> "RequestPolicy discussion" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/requestpolicy-discuss/-/FYGpJvZK_qkJ.
> To post to this group, send email to requestpol...@googlegroups.com.
> To unsubscribe from this group, send email to
> requestpolicy-di...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/requestpolicy-discuss?hl=en.
Thanks. Positive feedback is always appreciated.
> 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?
Having rules be able to include a path element (e.g. path prefix
"/reader/") is a planned feature in 1.x. When creating the new rule
system used in 1.x, I made sure that this could be supported. The big
question at the moment is when I'd have the couple of days I'd need to
implement and test this. Right now a couple of days is hard to find.
In a few weeks I'll have a much better idea of how much time I'll have
for RequestPolicy over the next six months. That's going to be a big
factor in how many features make it into 1.x this year.
Justin
There, that's about it. I hope I wasn't being too harsh. ;)
> For deny by default policy: There should be a way to add a default-blocked
> destination to the blacklist in the icon menu. Currently you have to first
> allow the destination so that the menu item appears that lets you block it
> permanently.
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.
> The current tab in the "Your Policy" page only lists the policies, but won't
> let you change them. You have to remove an existing one and add a new
> policy. Users should be able to edit the policies in place.
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.
> In the icon menu perhaps there should be some way to differ between items
> blocked/allowed by default and items in the white/blacklist. Perhaps make
> the permanently blocked/allowed items appear bold.
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.
> There, that's about it. I hope I wasn't being too harsh. ;)
Not too harsh at all. Hopefully my answers aren't, either.
Thanks for taking the time to provide feedback and suggestions.
Justin