-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perform multiple menu actions before reload of page #2
Comments
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. |
Replying to [comment:3 NukePower]:
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. |
Agree 100% with this. |
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. |
I take it back :/ This is very important. |
I agree that this is important. One of the sites that I use to demonstrate RequestPolicy (RP) usage with is Ebay. To be able to use such sites, RP users need to learn how to deal with such sites. Ways to reduce the amount of clicks needed once multiple choices are allowed before automatic reload:
|
From [http://forums.mozillazine.org/viewtopic.php?p=10339235#p10339235 famz]: 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. |
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. |
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. |
Thanks jsamuel for the words. I'm really looking forward to version 1.0 and will test the alpha right away :) |
Thursday Dec 22, 2011 at 18:44 GMT
Originally opened as RequestPolicy/requestpolicy#2
Some people would like to be able to perform multiple menu actions before the automatic reload of the current page. One good example of this being useful is with mobile devices that have low and costly bandwidth and thus slow reloads that waste data transfer.
The text was updated successfully, but these errors were encountered: