Perform multiple menu actions before reload of page

[requestpolicycontinued]

Perform multiple menu actions before reload of page

[msxfm]

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

---

imported trac comment
created: 2009-06-09 08:26:15
author: justin

My guess is that the best solution is some form of what !NoScript started doing, where selecting menu items doesn't immediately cause a reload but instead users have to click outside the menu area to indicate they are done. It means an extra click, so I probably wouldn't make it the default behavior. A user who wanted this could enable it through the preferences window.

An easier solution that would probably fulfill most needs for this is probably #3.

[msxfm]

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

---

imported trac comment
created: 2009-12-16 09:44:28
author: NukePower

+!

I prefer the NoScript mode of multiple changes before reload having not found 'hidden' preference in #3 as it is hidden or not yet available ;)

[msxfm]

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

---

imported trac comment
created: 2010-03-03 14:34:46
author: xenophore

Replying to [comment:3 NukePower]:

+!

I prefer the NoScript mode of multiple changes before reload having not found 'hidden' preference in #3 as it is hidden or not yet available ;)

The difference is telling when running both NoScript and RequestPolicy and they are almost next to each other in the status bar. Changing the status of 10 sites on NoScript requires only one reload, but on RequestPolicy, it requires 10. On long pages full of graphics from various sites, this gets rather tedious. This would be my highest priority requested enhancement for RequestPolicy.

[msxfm]

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

---

imported trac comment
created: 2010-03-29 09:23:13
author: IE Sux Mega

Agree 100% with this.

[msxfm]

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

---

imported trac comment
created: 2010-09-03 09:18:39
author: hablababla

I'd really love this too, it's (almost) a must. But as I said in [https://www.requestpolicy.com/dev/ticket/3 #3]:

I'd really prefer the behavior of #2 over this, but if it's too much work, theres more important things than this.

[msxfm]

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

---

imported trac comment
created: 2010-09-03 09:27:39
author: hablababla

I take it back :/

This is very important.

[msxfm]

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

---

imported trac comment
created: 2010-10-07 14:47:28
author: rainer

I agree that this is important.

One of the sites that I use to demonstrate RequestPolicy (RP) usage with is Ebay.
They use a lot of CSS, with ebaystatic.com, ebaydesc.com, ebayobjects.com, ebayrtm.com, ebayimg.com, paypal.com, paypalobjects.com, plus all those country-specific domains.

To be able to use such sites, RP users need to learn how to deal with such sites.
Power users can figure this out on their own, but for casual users it is better to show them. In addition, I want to be up front about the inconvenience to expect when using RP. Some users, when they see how much work it is to get Ebay running, say "no thanks". The less work it takes to get such pages to work, the better.

Ways to reduce the amount of clicks needed once multiple choices are allowed before automatic reload:

• Automatically reload once the last remaining blocked destination has been allowed.
• Automatically reload once the mouse pointer explicitly leaves the RP main menu area (only if at least one menu entry has been clicked). If a submenu item is clicked, and the submenu subsequently vanishes, do not auto-reload until the pointer has entered the RP main menu area and then leaves that (or a click is made outside of RP).

[msxfm]

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

---

imported trac comment
created: 2011-01-24 13:32:23
author: justin

From [http://forums.mozillazine.org/viewtopic.php?p=10339235#p10339235 famz]:
I would suggest that in case of a change, only the current sub-menu vanishes, and the main-menu persist so you can go to the next request w/o a page reload and anew open of the menu. To close the menu and force a reload of the page the user just has to click somewhere outside of the menu.

In case of "allow all request temporary", "allow all request through example.com temporary" or "cancel temporary authorizations" the menu should immediately vanish and a page reload should be triggered.

[msxfm]

Comment by l-i-r-n-f-a
Wednesday May 16, 2012 at 17:39 GMT

---

Referring to jsamuel's comment on issue #6 and its implementation in RP's forthcoming version 1.0 (RequestPolicy/requestpolicy#6 (comment)), may I ask if we can also hope for a solution of issue #2?

For reasons having to do with workflow I basically like the behaviour "auto-reload page after setting a rule" but it's kind of annoying if you have to set various rules one after another which in my case happens quite often. To me, for the same reasons (=workflow), #2 is preferable over #3 (which has already been implemented anyway and is nice for those who want it and even nicer as it's a selectable option ;) ).

Like suggested above I also imagine a solution similar to NoScript (changes getting into effect after clicking outside the menu). #2 should probably be a selectable option where you can choose between the "old" standard and the "new" NoScript-like behaviour so people have the choice.

Despite this #3 should be kept for those in need of it.

Thank you. RP is still one of my favourite add-ons.

[msxfm]

Comment by jsamuel
Wednesday May 16, 2012 at 18:16 GMT

---

I'm super happy to say that multiple menu actions before reload is implemented in version 1.0 alpha.

Version 1.0 has an entirely new UI which is not based on traditional menus. When the new menu closes (e.g. clicking outside of the menu area), the page will be reloaded if there are changes. I intend to keep the option of completely disabling auto-reload but I don't intend to make it an option that the menu closes as soon as any rule changes is made.

I never liked cramming RequestPolicy's information and rule options into traditional hierarchical menus. And even though NoScript's implementation of multiple rule changes with dynamically updated traditional menus is a great hack and almost certainly good for usability, it always feels a bit clunky to me. I'm not sure that can be avoided and I wanted a better UX. Whether I've achieved that is, of course, entirely subjective.

RequestPolicy's new UI also has a lot of great potential for ways to represent additional information to users in the future, though for now it's pretty much the same information that was in the old menu.

[msxfm]

Comment by l-i-r-n-f-a
Wednesday May 16, 2012 at 18:45 GMT

---

Thanks jsamuel for the words. I'm really looking forward to version 1.0 and will test the alpha right away :)