Comments (11)
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.
from requestpolicy.
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 ;)
from requestpolicy.
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.
from requestpolicy.
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.
from requestpolicy.
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.
from requestpolicy.
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.
from requestpolicy.
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).
from requestpolicy.
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.
from requestpolicy.
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.
from requestpolicy.
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.
from requestpolicy.
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 :)
from requestpolicy.
Related Issues (20)
- [WebExtension port] data storage, privacy settings HOT 2
- [WebExtension port] URI class, DomainUtils, PSL
- re-create unlisted channel HOT 3
- "Advanced Preferences" incomplete HOT 1
- create a βstatusβ page HOT 4
- unable to install the newest build i.e. 1.0.beta13.2.2448.r2f5182f6.pre HOT 2
- Unable to view 3rd party requests to domain and nothing happening for temporary requests. HOT 2
- Unable to install the newest requestpolicy 1.0.beta14.0.2464.r87523672 in Firefox 60.0.2 HOT 2
- UI navigation problem - returning to top domain HOT 5
- documentation (and wiki) discussion HOT 7
- Fx 48 refuses to update to RPC14 HOT 3
- firefox: cannot install a nightly build HOT 4
- Pale Moon Add-ons Site HOT 2
- reCaptcha label:"help wanted" HOT 6
- can't compile or make requestpolicy HOT 3
- Your link: 0.5 version still available on Addons for Firefox HOT 1
- Old version of RequestPolicy? HOT 2
- re
- Minor change required for Pale Moon 30+ compatibility
- Is there a RequestPolicyContinued version for seamonkey 2.53 ? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from requestpolicy.