v1.0 has no menu entry in the context menu (right-click menu)

[msxfm]

edit by @myrdd

RequestPolicy 0.5.x had an entry in the right-click context menu, see this screenshot:

In v1.0 beta this additional menu disappeared. This issue is about getting that menu back.

---

---

original post

Issue by Dinoso
Wednesday Nov 28, 2012 at 17:59 GMT
Originally opened as RequestPolicy/requestpolicy#353

---

Hi,

please add an option to have the menu of version 0.5 again. I was familiar with right-clicking whereever I was, move cursor to requestpolicy, do my action (sorting is already filed here, so I won't go into this) and after clicking whatever I wanted to, the menu closed and depending on my preferences the site was reloaded or not.

I really like the new features, but I want the old (quicker) behaviour again, at least as an option.

[msxfm]

Comment by Jookia
Saturday Sep 28, 2013 at 01:28 GMT

---

I'd like this too, as all my other add-ons do this.

[myrdd]

I'd like to implement this for version 1.0

[myrdd]

I've started working on this. My goal is to create a menu that is as simple and intuitive as possible.

I would like to make the old-style menu the standard menu, and call it "simple menu". The current menu in 1.0 (beta) will be available through an option and could be called "extended menu". It could contain much more information than the simple menu, but I think that most people don't want/need this.

So far I've created a menupopup which contains also a list of destinations:

[nodiscc]

@myrdd I, for one, prefer the new menu. Colors make it more understandable, the blocked/allowed sections make it clear what's blocked/allowed with a quick look... The old menu was nice but you have to navigate it a bit to know about blocked requests. Some menu entries (prefs, request log) are not frequently used, so having them in light gray, small font makes sense (in the old menu they "clutter up" the interface a bit).

What advantages do you see in reverting to the old menu? It's great to have an option for it but RP should default to the new menu IMHO.

[myrdd]

What advantages do you see in reverting to the old menu?

Good question. In fact my main idea was to have a menu which is as simple as possible. I had a discussion with some friends about the menu design mainly regarding the "complexity". We compared the menu to that of NoScript and recognized that NoScript is easier to handle with because you only have one domain, not two (origin/dest). We concluded that most users probably only want to say "I trust that domain" instead of "I trust this domain, but only from the current domain".

As I can now see, you prefer the new menu, so the default menu is still to be discussed. Having the old menu in newer versions creates some kind of backwards compatibility of the design. In addition, the "classic" style is somewhat known from many other menus (e.g. context menu, …).

However, a "simple menu" which displays only the destinations (origin is always *) could be implemented also in the new menu. In fact, we could toggle the different "levels of displayed information" on the fly, so we're way more flexible than with the old-style menu. I'm not really sure what we should do…

Colors make it more understandable

font colors are possible (but maybe not advisable).

The old menu was nice but you have to navigate it a bit to know about blocked requests

I see two possibilities

• having a menu similar to NoScript's menu. That is, having two entries for each destination: allow destination permanently and allow destination temporarily (in case of default-deny). As soon as you click one of the two entries, the two entries disappear and a new one appeares ("block destination").
• having a submenu for every destination like in 0.5 but displaying sufficient information in the "main" menu – whether a rule exists e.g..

Some menu entries (prefs, request log) are not frequently used […](in the old menu they "clutter up" the interface a bit).

that's right. but noscript also has some seldom used menu entries on the top. we could position them on the bottom.

So what should we do? More opinions are very welcome!

[aspensmonster]

I'm adding my own voice to the request to keep the old UI from the 0.5.x series. It's very detailed. It works. It follows the same UI style as NoScript and CookieMonster, which when combined with RequestPolicy, serve as a very fine-grained control over how the browser handles scripts, requests generated from those scripts, and cookies. The newer interface feels entirely too minimal to me. I know the trend is to simplify everything to death and remove "buttons only used X% of the time," but I don't think the userbase of theses types of add-ons would benefit from that approach.

[myrdd]

Thanks for your opinion @aggroskater. So we will have the old menu still in 1.0.

I'd like to discuss about the structure of the menu in general. Therefore I'll clarify my previous post:

I see two possibilities

• having a menu similar to NoScript's menu. That is, having two entries for each destination: allow destination permanently and allow destination temporarily (in case of default-deny). As soon as you click one of the two entries, the two entries disappear and a new one appeares ("block destination").
• having a submenu for every destination like in 0.5 but displaying sufficient information in the "main" menu – whether a rule exists e.g..

In v0.5 we had a menu like this:

So the structure was:

• destination DestA
  • (1) allow/block Origin --> DestA
  • (2) allow/block * --> DestA
• destination DestB
• …

(As RP 1.0 handles "other origins", besides (1) and (2) there could be OtherOriginX --> DestA, too.)

The menu structure could be kept as above, but I'd like to emphasize the * --> Dest rules instead of Origin --> Dest. The reason is, as I said above, I think:

most users probably only want to say "I trust that domain" instead of "I trust this domain, but only from the current domain".

So the * --> Dest rules could be placed

1. either on the top of the submenu
2. or in the main menu like in NoScript.
   The second option might have the disadvantage of a long list in the main menu, as there will be two or three options per destination. Maybe the choice about the structure of the rules should be an option?

[aspensmonster]

I'd agree that the first option is better. I suppose I was rather vague about the UI style :D Whether the options are in the topmenu/"main menu" like in NoScript, or in a submenu like in your image, the important thing is that they are there and accessible without needing to navigate away from the current tab.

[nodiscc]

most users probably only want to say "I trust that domain" instead of "I trust this domain, but only from the current domain".

I agree with this. There should be a third action available to trust a destination only from the current domain (e.g. I trust youtube.com to request data from google.com, but not other sites to do so)

The second option might have the disadvantage of a long list in the main menu, as there will be two or three options per destination.

Agreed. Having the action in the submenu looks like the best option.

[...] seldom used options. we could position them on the bottom.

I think this is reasonable.

I'm adding my own voice to the request to keep the old UI from the 0.5.x series. [...] I know the trend is to simplify everything to death and remove "buttons only used X% of the time,".

Actually @aggroskater you made my point. I'm not opposed to the 0.5x style menu, as long as it preserves some features that the 1.0 menu has:

• every blocked or allowed domain is clearly visible (not nested) right after opening the menu.
• red/green colors. It might be a problem with some GTK themes, but it really makes the menu easily readable (as it can grow large).
• prefs/requests log/help/manage policies/disable blocking are not hidden away.

the current 1.0 menu lacks the first-level Allow all requests from $currentsite action, something I'd like to be re-introduced.

[myrdd]

okay @nodiscc, I agree completely.

Side note: the current 1.0 menu lacks the first-level Allow all requests from $currentsite action and it is something I'd really like to be re-introduced.

click on the origin and you'll get this option:

[aspensmonster]

Sidenote: I find both the 0.5.x and 1.0.x menus usable. I'm in agreement with @nodiscc about making sure all of the options are still available though regardless of which UI is present. If time is scarce, then we can always let the 0.5.x-style context menu option slip to a later point release --or even figure out a way to tweak (or else permit the user to tweak) the 1.0.x-style menu sufficiently such that including the older style isn't necessary.

[CrashNBurn71]

|| slashdot.org
||
|| [√] [ ] rpxnow.com >>
|| [Θ] [ ] fsdn.org >>
||

Clicking on the icon on the left would toggle between Allow/Deny (from slashdot.org)
The second empty 'icon' [ ] when clicked could add a "*." loosening for the domain
The submenu could be:

|| Allow fsdn.org (temporary)
|| Allow fsdn.org from any domain.
||
|| Customize Rule

And:

|| Deny rpxnow.com (temporary)
|| Deny rpxnow.com from any domain.
||
|| Customize Rule

With the icon on the left toggling allow/denies, then you don't need to show Denies AND Allows in the submenu, making the interface cleaner for those that want a simpler one.

Customize Rule would open the main rules page, with those domains prefilled in the text boxes
so that you could change what level of strictness you wanted or other options that may not need
to clutter the context menu.

Or Cutomize Rule, or another phrasing could just temporarily open the new 1.0 menu that we have now in all it's glory.

Personally, I'll just keep using the new Drop-down, its really good.

[SkySkimmer]

Personally I prefer the new menu for being able to enable a bunch of sites without having to open the menu again for each, and for not having to be precise with mouse movements to avoid closing submenus. Controlling submenus with clicks instead of mouse position is far better.
More strictness options would be nice but we already have an issue for that.

[riesza]

Another voice for at least some kind of context menu, old or new. I would like my Firefox to stay clutter-free and would appreciate a context menu entry option. Hopefully this is still being worked on.

edit: awesome!

[myrdd]

Hi @riesza, the milestone for this issue is 1.0 stable.

[ghost]

Hi, is the right click menu already functional? I have installed the latest beta but there is only a button in the toolbar. I'll downgrade to FF 37.0.2 until this works. Thank you for your efforts.

[ghost]

I was even so desperate to edit the em:maxVersion in the install.rdf of the 0.5.28 release because I want the context menu but it gets blocked anyway.

[riesza]

If you don't want to litter your toolbar with the RP icon there's a shortcut to bring up the menu: ctrl+alt+R

[myrdd]

@noisybe if you want to use the old 0.5 version, you can try RPC 0.5; I've just uploaded it to AMO, it should work – but don't forget to uninstall legacy RP.

The right-click menu is not there yet. It's currently planned for 1.0.beta12

[ghost]

@myrdd wow.. I hadn't found that. Thank you! <3

Looking forward to 1.0.beta12 :)

[myrdd]

@noisybe you're welcome! Btw, you did not find it because it's still in the AMO Review Queue.

[myrdd]

The next version will have a context menu entry again. When you click it, the "normal" 1.0-style menu will open, just like when you click the toolbar button.