Make a preference temporary for just this session #731
Comments
|
I need to fix this sooner than later. |
|
just my thought, would it be possible for the lock button be made little smaller than now. It looks lot bigger. |
|
EDIT: Oops, now I see. Does that mean that the regular, one click to set permanently, is now no longer a permanent one but rather a session-only ? I don't get it, a one time click now brings the open lock (which makes me think "not permanently") into view, ???? |
|
Edit: I found it. Is it the lock icon? Edit 2: IF it is the lock icon how does it work? |
|
It's more like uMatrix now: the rules are temporary by default. If you are happy with them, save them by clicking the padlock. When there is no padlock, this means there are no temporary rules in the list. |
|
@harshanvn Looks fine to me. You have a screenshot so that I can see how it looks on your side? |
|
@gorhill i guess it is just a matter of taste. If its compared to Element picker/network request logger icon, it seems to be bigger.
|
|
@harshanvn Ok, by design. Looks fine to me. |
|
hmm...ok Then. No Problem. Just needed some time to get to :) |
|
It might spoil it for some newer users, stating "but I disabled that yesterday, and today it is back", |
|
@Betsy25 With uMatrix, this proved to be the best way to work. As long as it is documented, an advanced user shouldn't have any problem with this. At first, one will have to padlock often to save rules for one's usual sites, but pass that, having rules temporary by default is very convenient. How else would you do this? I am certainly not in favor to clutter the UI with huge amount of options, NoScript and RequestPolicy UI are definitely not the way to go with their huge lists of duplicate entries, one for temporary, the other for permanent. Edit: Here is a challenge for those against the new way to work: provide an alternative solution, not just a statement that you think the current way is not the right way. |
|
The way I see it, as the vast majority of advanced feature users will want to preserve the actions they take, takes 1 single click. |
I completely disagree with this. My rules are already built for the most part, and I find myself now very annoyed that whenever I just allow one 3rd-party to un-break a web site which I will never visit again, that rule is polluting my good ruleset. It's why I made it a priority to fix this. Once the rules for your usual web sites are set, the likelihood is that all the new rules will not be for beyond the current session. I have uMatrix to back this up, this is how it has worked since forever now, and having to click the padlock, nobody has asked me to change this. |
|
@gorhill Yep, sorry for the disturbances, You're perfectly correct, sorry that I didn't think this out any further. |
|
I completely support the temporary default with the lock option. However, I think you should offer something like "shift-click" to be a one-click permanent option. That will satisfy the people complaining about the extra click, and it will allow mixing and matching of temporary and permanent rules. Oh, and thanks for the fast work on this!! |
|
For translators:
|
|
Why not enabling this "feature" after clicking the "I am advanced user" with another nested checkbox in the dashboard? Why not having uBlock highly customizable and not enforce every advanced user to use uBlock like what is convinient it is for some amount of users? (if he is an advanced user, let him customize the behaviour to his likings, right?) I, personally, would like to revert to the current behaviour - 1 click to permanently change the preference. |
|
@Mikey1993 Why is this an issue now? You never mentioned this with uMatrix. |
|
@Mikey1993 disagreed. I think this paradigm is fantastic. |
|
@gorhill Because I didn't see it feasable to revamp the wheel when a lot of people are already used to this, as this is how uMatrix is working for a long time. @chrisaljoudi This is what I am trying to point, everyone has their own preferences, just as I don't like to be forced to click more accomplish the same before this change. Isn't that sounds logical? |
|
@Mikey1993 it sounds logical; it's just not true, in my own humble opinion. Given the nature of how µBlock stores the rules (no central server for backups or preference storage), and given how easy it is to overwrite something and lose it, the extra click is very reasonable. The rules actually start being applied as soon as you put them in Temporary Rules, and your temporary rules remain there until your session is restarted. If you decide that your rules don't radically break things, you can commit them and now they're stashed and saved. The types of changes you will be doing frequently are types of changes that are temporary. Permanent changes are, in comparison, done very infrequently. There's an arbitrary number of ways to do this — what they differ in is usefulness and helpfulness. It's useful and wise not to have to worry about losing longer-term rules when experimenting. |
|
@Mikey1993 By the way, you can also commit all your rules at once from the My rules tab, so you can skip having to save them every times if this annoys you. |
|
One argument is also that in in |
|
Well, I still can't simply agree with all the "workarounds" and the view about how more options only to advanced users can harm the functionality of a given program. People will always ask about how to use your program the second it's more complicated than 2 clicks, that is a plain fact. I truly can't see why implementing the option to unsubscribe to "click 1 more time" "feature" is such a bad idea. |
|
@Mikey1993 What I can't understand is such a reaction from someone who never questioned the same feature in uMatrix. |
|
@Mikey1993 the option isn't a bad idea, it's just not a good idea either, IMHO. It seems relatively arbitrary to me. Customizability's good, until it's a pain for users and/or implementors. Have you ever tried to read a really, really, really long It seems like having a long list of checkboxes in the Preferences page harms the 90% of users a lot more than it benefits the 10% (assuming that it is actually desirable to have this). Like I said: making permanent changes is very infrequent. I'm puzzled: is this just by principle, or is there a use case you're concerned about? TL;DR: µBlock can't have a toggle/switch for every possible aspect. As you abstract and factor that out more and more, µBlock becomes less of a tool and more of a framework/programming language in a sense. That doesn't seem like the goal. In any case, I'm sorry for intervening in the discussion, @gorhill and @Mikey1993. |
What would be the exact wording you would use for such a setting? |
|
I would suggest the padlock still been shown, at least briefly, after clicking or ctrl+clicking, in order for the user to receive feedback on whether was a permanent or temporary rule. |
|
@alejandrolemus well, the open padlock must still be shown because that's a separate function. The normal process for almost everyone always will be to make a rule temporary and sometimes choose to later keep it permanent. So they'll want to see the padlock and be able to use it to make-permanent the temporary settings. I don't yet fully understand whether the padlock will be "make permanent all temporary settings" or some other function. If it is that, then it does not make sense to show it as locked each time someone ctrl-clicks. The locked image would mean that all adjustments are permanent and unlocked means some temporary ones are active… I think… I might be a little confused… |
|
@wolftune I think you are right, if rule is permanent, there is no point in showing the padlock. If I got it right, it is only there to commit temporary rules. |
No, what is a trivial sentence, "padlock still been shown, at least briefly", is actually quite a whole lot of complicated code. Currently it's how ot works: if the padlock is there, it's because there is at least one temporary rule in the pane. That's about it. Sticking to that strict definition will remove any possible confusion. |
If the padlock is not visible, this means the rule was saved. |
|
@gorhill this is not regarding the padlock, but the minifirewall in general. Do you think people would find it easier to understand if the names were "Sandbox"/"Stored" instead of "Temporary"/"Permanent" |
|
@gorhill I think it's great that the ctrl-click function allows per-item permanence instead of just locking in the whole set all at once. But about situations with a mix in terms of UI feedback? If something is temporary and something else is permanent, what will identify to the user reviewing a little while later which rule has which status? |
|
@chrisaljoudi I think "temporary" and "permanent" are most clear and recognized, but that's not a strong feeling. Certainly it's what RequestPolicy and NoScript use. |
|
@gorhill yes I noticed before. Comment timing :) @chrisaljoudi sorry to get in the way, but pretty please no. I'm a user, not very a savvy one, but a user. Temp/Permanent is way better IMHO. @wolftune the Settings page? Edit: (screenshots earlier in this thread) |
|
There's something definitely not quite right here. Here are the steps I take and the results they give me...
Anyone can reproduce ? EDIT: Same experience when just simple clicking instead of ctrl-clicking. |
uMatrix has some UI to distinguish permanent rules from temporary ones. But it's a part I spend a ridiculous amount of time to work out, and I've never been satisfied completely (too many visual cues can quickly become noise). That said, I think it's fine for now what we have in uBlock, I prefer the wait and see. We can always invent more issues but I prefer that whatever is deemed an issue confirms itself over time through feedback. So currently I will be conservative and stick to the definition "there is a least one temporary rule in the pane". If a user like the result of the current rules on the web page, lock the state of the pane down. There is always the "My rules" tab in the dashboard to sort out what is temporary/permanent at a glance. |
|
@gorhill Sounds like good thinking to me overall. Don't do work if it's not really needed. If it were considered any further, I think I'd suggest a little icon of something indicating temporary status next to or over any temporary setting. But yeah, could be a someday/maybe issue. |
|
If anything, we probably need an eraser aside the padlock, just like in uMatrix. But I will wait for now, and if needed that should go in its own issue. |
|
@gorhill One last detail: when does the "session" end? Is it quitting the browser or just leaving the site? I was thinking about an eraser function, like a "remove all temporary" but knowing what will reset the session is an adequate workaround for now… |
|
When restarting the extension. |
|
What's the fastest way to restart the extension? |
|
@gorhill or anyone else, One last thing, can you please try to reproduce the issue explained in my previous post |
|
@Betsy25 Open a separate issue please. I tried to repro and could not. Will need more details, but we can't keep throwing more stuff in here. |
|
@wolftune If it's for the purpose of removing all temporary rules, just use "Revert" in the "My rules" tab. |
Request Policy and NoScript and others have mechanisms for temporary settings. So, I'd like to be able to allow something temporarily and know that it will not persist as a setting, but will revert automatically next session.
The text was updated successfully, but these errors were encountered: