Skip to content
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

discussion: redo 0800s location bar etc #32

Closed
crssi opened this issue Feb 25, 2017 · 18 comments
Closed

discussion: redo 0800s location bar etc #32

crssi opened this issue Feb 25, 2017 · 18 comments

Comments

@crssi
Copy link

crssi commented Feb 25, 2017

Is there a reason that search suggestion from bookmarked and opened tabs are disabled?

I am using the following:
browser.urlbar.maxRichResults = 8
browser.urlbar.suggest.bookmark = true
browser.urlbar.suggest.openpage = true

Just can't see any privacy problems here, only productivity improvements.

Also accessibility.typeaheadfind = true seems nice productivity improvement.

For dom.event.contextmenu.enabled I am not sure about privacy/security (?), but some pages (outlook web access for example) provides additional control over context menu.

@earthlng
Copy link
Contributor

earthlng commented Feb 25, 2017

I also use the 1st 3 prefs, not a fan of typeaheadfind (prefer CTRL+F), and agree that dom.event.contextmenu.enabled needs some looking into regarding privacy/security.

We could create a section or sub-number (f.e. 0850) for physical location / spying / shoulder surfing, etc VS productivity/convenience/usability, and comment them out by default so users can enable them if they need protection against cam-surveillance, shoulder surfing, etc.
I imagine a majority of users are in a "safe environment" and would prefer the productivity improvements, etc.

IMO we can add accessibility.typeaheadfind as "enable typeaheadfind = true" and comment it out, under the personal section.

EDIT: fe. 0803 -> 0850a, 0805 -> 0850b, etc. (there are only 5-6 with "shoulder surfers" atm)

@Thorin-Oakenpants Thorin-Oakenpants changed the title search suggestion and context menu discussion: redo 0800s, also look at context menu Mar 8, 2017
@earthlng
Copy link
Contributor

earthlng commented Mar 8, 2017

Love it, love it, love it!

0809 - with browser.search.suggest.enabled=false the prompt never shows up. if it's true and browser.urlbar.suggest.searches=false, it'll show the prompt

Would you like to improve your search experience with suggestions? Learn more... [yes/no]

We can either ditch it completely, add it to 0807 or leave it as a separate item. I don't care.

now for some nitpicking and other ideas...

I would still add the test-link for 0805 so that users can see for themselves that it is still a problem.
With a note behind the test-link that the test only works in a normal window.

Instead of This setting is under Options>Search>Provide search suggestions we could use [Setting] Options>Search>Provide search suggestions, because it's not really under, it's that setting (Provide search suggestions)

0804 - I have mine set to 10 for convenience and use the history.length-spoofing userscript.
Idk if we want to move 0804 to 0850+ too and recommend and link to our userscript instead. or not. just an idea.

yeah, not much more to say, I love it - great job!

ps. download history retention pref - I don't think does anything but feel free to test yourself.

edit:

^^ am thinking even

I like the first version better. Or you could add another line to the first version:
/*** 0850: browser.urlbar.* convenience/functionality vs privacy/paranoia ***/
or something like that

@earthlng
Copy link
Contributor

earthlng commented Mar 8, 2017

yeah, it was more food-for-thought, not something I feel strongly about. Since we want to make this more appealing to a broader community, a slightly higher "default" value maybe wouldn't hurt, and the truly paranoid can still set it to 2 or do whatever - the info is all there.

@publicarray
Copy link

publicarray commented Mar 8, 2017

@Thorin-Oakenpants just in case you didn't know with the markdown syntax you can tell GitHub the language in the code block:

```
/* comment */
user_pref("foo", "bar");
```

/* comment */
user_pref("foo", "bar");

```js
/* comment */
user_pref("foo", "bar");
```

/* comment */
user_pref("foo", "bar");

I just think it's easier on the eyes. Keep up the good work guys 😺

@Thorin-Oakenpants Thorin-Oakenpants changed the title discussion: redo 0800s, also look at context menu discussion: redo 0800s location bar etc Mar 9, 2017
@crssi
Copy link
Author

crssi commented Mar 9, 2017

I can test this. Will try today, but to be sure just give me a day or two, if today something come in between. ;)

@crssi
Copy link
Author

crssi commented Mar 9, 2017

OK... first observations.
Testing is done with a clean default profile.
Installed SQLite Manager extension.
Connected to moz_formhistory table in formhistory.sqlite database.

Defaults:
browser.formfill.enable = true
browser.formfill.expire_days = 180

Testing with defaults... no surprises here... obviously. :)

Testing with:
browser.formfill.enable = true
browser.formfill.expire_days = 0

This one remebers formfills even when browser is restarted. My first thought would be that formfills data are forgotten instantly or at least after restart on a first day, but no.
Actually browser.formfill.expire_days = 0 does exactly nothing.

Testing with:
browser.formfill.enable = false
browser.formfill.expire_days = <doesnt matter>

Formfill data are not written into database as expected and data are forgotten instantly.
But all data from before remains even with restart.
Expected that privacy.clearOnShutdown.formdata = true would clean it up, but no.

Now I need to test it with:
browser.formfill.expire_days = 1 and will see tommorow.

Do you have any additional test cases in mind?
If so, just throw it here and I will test it.

Cheers

@earthlng
Copy link
Contributor

earthlng commented Mar 9, 2017

added this

👍

browser.formfill.expire_days - it looks like the code is never actually triggered except in a test-file.
First of all, idk what this line is good for, there's exactly one line of code that uses formhistory-beforeexpireoldentries

sendNotification("formhistory-beforeexpireoldentries", expireTime);

The function expireOldEntries is only called once as far as I can see:
FormHistory.expireOldEntries();
and is only triggered when the observer observes formhistory-expire-now, but the problem is only 1 test ever sends that trigger: formhistory-expire-now

Maybe I'm missing something. Help?! ;)

edit: for testing we can enable browser.formfill.debug and see if that helps

@crssi
Copy link
Author

crssi commented Mar 9, 2017

@earthlng Should I do any additional tests for browser.formfill.expire_days?

@earthlng
Copy link
Contributor

earthlng commented Mar 9, 2017

Does browser.urlbar.oneOffSearches require browser.urlbar.suggest.searches

No. FF52 also seems to have fixed the dependency on keyword.enabled. And it even works with browser.urlbar.maxRichResults=0 contrary to what @pyllyukko has stated here

0819: disable one-off searches from the addressbar (FF51+)
Covered by browser.urlbar.maxRichResults

I really like it and IMO we should ship with browser.urlbar.oneOffSearches;false commented out.
edit: unfortunately the default is still false, so unless we want to change it to true, it doesn't matter if we comment it out or not atm.

@crssi
Copy link
Author

crssi commented Mar 9, 2017

@Thorin-Oakenpants

  1. did all steps... it looks like browser.formfill.expire_days does nothing, the form data is collected when value is 0,1,90,180... restart does nothing to timestamps, existing data is not updated in any case
  2. didn't understand what you wanted exactly here :(

@earthlng
Copy link
Contributor

earthlng commented Mar 9, 2017

@crssi

  1. thanks for testing and confirming that. Looks like the code I looked at wasn't lying :)
  2. I don't either. I can't speak for Pants, but I for one appreciate your inputs, feedback and testing a lot! thx

@crssi
Copy link
Author

crssi commented Mar 9, 2017

@earthlng
Hey, its a least I can do. And yes, your sight is just fine. :)
I would like to spare you as much time I can, since I am aware how much you are already investing in it.
It is me who needs to thank you guys.

@crssi
Copy link
Author

crssi commented Mar 10, 2017

I am a bit puzzled why privacy.clearOnShutdown.formdata = true does not clear formdata from moz_formhistory table in formhistory.sqlite database. Is this a FF bug?
Or its something wrong with my test observations? It could be latter, will retest it sometime today.

EDIT:
Its me and my stupidity.
I was testing on plain vanila FF settings and forgot that privacy.clearOnShutdown.formdata is dependant on privacy.sanitize.sanitizeOnShutdown which I had default ("false"). "true" works as expected.
Sorry for "spam".

@crssi
Copy link
Author

crssi commented Mar 10, 2017

browser.download.manager.retention does nothing... at least not the value of "0", which should be "remove upon successful download"... it looks like deprecated.
Extension Downloads Window has function to remove finished downloads from the list immediately when download finishes.

@earthlng
Copy link
Contributor

earthlng commented Mar 10, 2017

damn Pants, got up early today to read your response to our little rants from yesterday and now they're gone :(
I fully stand behind everything I said - yes I know it probably didn't help with making friends and made me look like a total asshole, but who gives a fuck

@earthlng
Copy link
Contributor

earthlng commented Mar 13, 2017

bump .. is this good to go?

let's see... I'll re-post parts of my previous comment here re: nits

Pants: Is 0809 a LIVE pref or just a suggestion to use the search engine from the urlbar?

Earthlng: with browser.search.suggest.enabled=false the prompt never shows up. if it's true and browser.urlbar.suggest.searches=false, it'll show the prompt
Would you like to improve your search experience with suggestions? Learn more... [yes/no]
We can either ditch it completely, add it to 0807 or leave it as a separate item. I don't care.

You've since added browser.urlbar.userMadeSearchSuggestionsChoice to 0808.
I propose something like this (as a format I'd prefer in some cases, going forward)

/* 0807: disable search bar LIVE search suggestions - PRIVACY ***/
user_pref("browser.search.suggest.enabled", false);  // Options>Search>Provide search suggestions 
user_pref("browser.urlbar.suggest.searches", false); // Options>Search>Show search suggestions in location bar results
user_pref("browser.urlbar.userMadeSearchSuggestionsChoice", true); // (FF41+)

Because the titles are essentially the same for both 0807+0808 anyway

I would still add the test-link for 0805 so that users can see for themselves that it is still a problem.
With a note behind the test-link that the test only works in a normal window.

You've added the testpage with a note. If I'd change anything it'd be to shorten that line, fe.
[TEST] http://lcamtuf.coredump.cx/yahh/ (see github wiki APPENDIX C on how to use)
Optionally also drop the "on how to use"

Instead of This setting is under Options>Search>Provide search suggestions we could use [Setting] Options>Search>Provide search suggestions, because it's not really under, it's that setting

All done. Glad you liked it.

0804 - I have mine set to 10 for convenience and use the history.length-spoofing userscript.

you changed it to 10, nice. Do we want to include a link to the userscript?

Or you could add another line to the first version:
/*** 0850: browser.urlbar.* convenience/functionality vs privacy/paranoia ***/

I still think this would be nice - it would slightly separate the 0850+ lines a bit better visually.

user_pref("browser.urlbar.userMadeSearchSuggestionsChoice", true); // (FF41+)
/* 0850: browser.urlbar.* convenience/functionality vs privacy/paranoia ***/
/* 0850a: disable location bar autocomplete ***/
   // user_pref("browser.urlbar.autocomplete.enabled", false);

Most importantly from all this I really think we should comment out all the 0850 prefs by default.
If we do that then the description in the section header will need some adjustments.

nothing more to add - as always, take it or leave it - this is good to go then. good job! Thanks!

@earthlng
Copy link
Contributor

I really think we should comment out all the 0850 prefs by default.

To clarify - I'd only comment out the 085x prefs. 086x are already commented out and 087x should definitely remain active because they "pollute" the C drive by creating a file in
C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations
Idk if portable prevents that (it really should, imo) but I doubt that it does.
I think the ID in browser.taskbar.lastgroupid is what's used for the name of the file, if you want to check.

@earthlng
Copy link
Contributor

earthlng commented Mar 13, 2017

one is search bar, one is location bar

ok, my bad, I read it as urlbar and location bar

separation line for 0850+ nah, people need to learn to read, also it's not just browser.urlbar*

all the 085x prefs are browser.urlbar.*

Thorin-Oakenpants referenced this issue in pyllyukko/user.js May 22, 2017
As discussed in #208

The URL suggestion is controlled by browser.urlbar.autocomplete.enabled
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants