Privacy Browser Android

Soren you have done wonderful thing to create this Privacy Browser. But I too must join the growing list of users who much prefer the old long-press behaviour with individual bookmarks. Yet I also would be okay with change #926. So I wish you could do #926 combined with undoing #912. (I have also posted this comment on https://redmine.stoutner.com/issues/926). Thanks very much.

#926 will be implemented regardless of what happens with this feature request. The only hesitation with implementing a setting that changes the long-press behavior is that I generally do not like having settings that modify the GUI (most settings modify how the backend works). Settings that create a separate code path in the GUI tend to add a significant maintenance burden because all of those code paths must be tested in combination anytime any part of the GUI is modified, and because they tend to break with future versions of Android more than other types of settings do. Even more importantly, I have received dozens of requests for GUI modifications that a small number of users would find helpful but most users would not. If I implemented them all the settings screen would become a mess of difficult-to-understand options. I personally dislike trying to navigate apps with tons of confusing settings like that and I am not inclined to impose that experience on Privacy Browser's users.

I have made a few exceptions to this general policy in the past. For example, there is an option to move the app bar to the bottom of the screen and there are controls for day and night mode. In both of these cases there are a significant percentage of users that take advantage of these options, so that user base justifies the effort. There are other examples with less users, like the options to display additional app bar icons and enable full-screen browsing mode. In both of these cases, I feel that the number of users who take advantage of these is still orders of magnitude larger than those who would open a bunch of individual bookmarks at once from the bookmarks drawer.

Therefore, my default inclination is to not implement this feature request. However, there has been enough interest expressed that I have created it so that those who are interested have a dedicated space to express their desires. If there is enough interest, or if someone can point out some aspect of this that hasn't already been discussed, I am open to changing my mind.

Now, if I close the drawer with the "<-" arrow icon and reopen the drawer again, I would love to see the pin active again (remember last state). And voila, we (nearly) have the old behaviour back (and we don't need an additional setting for it) :o)

....Or instead of all this, could just do the simplest thing: revert change 912 and restore the prior longpress behavior :) Given all the other users who share this preference it seems there's no compelling reason to keep that change...

Pinning the bookmark drawer is an interesting idea. I would need to think about the details of the implementation, but I could see myself going with that.

As I have already explained more than once, #912 is not going to be reverted because it is in the best interests of the majority of users. Please do not request it again unless you have some information to add that has not already been thoroughly discussed.

Thinking through the desired behavior of a pinned drawer, I would assume that tapping a bookmark should open that bookmark in the current tab and close the drawer, but long-pressing a bookmark should open it in a new background tab while keeping the drawer open. The drawer could be closed at any time by tapping in the background space, swiping the drawer closed, or tapping the back arrow. The drawer would stay pinned when reopened, but would revert to being unpinned when the app restarts.

Does anyone recommend a different behavior?

I have a slightly different idea about the operation with a pinned bookmark drawer:

• tapping a bookmark: open the bookmark in a front tab, and keeps the drawer open/pinned (otherwise there wouldn't be any difference to the not pinned drawer) (front tab is the opposite of a background tab)
• long-pressing a bookmark: open the bookmark in a background tab, and keep the drawer open/pinned (old behaviour)

• swipe the drawer back/closed
• use the arrow on top (if we are in the bookmark root and not in a subfolder)
• use Android's back key (well, I'd love to see the old back-key behaviour to navigate the subfolders ;o)
• unpin the drawer

• if possible, persist the pin status even after the app restarts (but I don't know about the effort)

My current workaround to the not-being-able-to-open-bookmarks-in-the-background-anymore is that i've copied all my bookmarks to a file and opening said file with a file manager app where it's then opened with PrivacyBrowser, because opening links in the background is still possible. Since this is a particular clumsy and inefficient way of handling bookmarks i would like to ask if there is a way to make PrivacyBrowser open that file as the homepage. (Opening via file://path/to/file doesn't seem to work) This is not meant as a feature request, i am just still fairly new to the whole android system, so i'm just curious if it's possible in general to open local files directly in the browser.

Privacy Browser cannot access public files using file:// URIs due to restrictions in Android's Storage Access Framework. You can read a bit about this at https://www.stoutner.com/privacy-browser-3-7/.

If you place your .html file somewhere on the internet and access it via an https:// link that will work. Also, if you have another app on your phone host the file and provide it to Privacy Browser via a content:// URI that will work as well. Note that in this case you need the content:// URI to be persistent. Some apps provide a content:// URI that expires when the app or the device is restarted. Others provide a persistent content:// URI that works in perpetuity. An example of an app that does this is Nextcloud. The file browser you are already using might also produce a persistent content:// URI. If such is the case, you could just make that URI your homepage.

Soren Stoutner wrote in #note-10:

pin state:

• if possible, persist the pin status even after the app restarts (but I don't know about the effort)

This would require creating a setting in the main Settings screen that controls the default pinned status of the bookmarks drawer. I am opposed to this for some of the same reasons as listed above.

I'm not sure, there is the need for a "Preserve pin state for bookmark drawer" setting in the settings screen. It's a UI setting, (hopefully) self-explanatory and the user sets it explicitly already in the bookmark drawer. But it's your software and you should follow your own guidelines.

There are two ways to preserve settings across an app restart. The first is to use Android's Preferences system (this is what populates the Settings screen), which saves the settings in an XML file managed by the OS. The second is to use a custom SQLite database (this is what Privacy Browser uses to store bookmarks and domain settings).

Using the Settings system requires less work on the part of the developer. SQLite databases require a lot more plumbing of code. If I were to try to save this setting I would probably just add it to the Settings screen. However, I am more inclined to just make it an ephemeral UI that resets on each app start.

Soren Stoutner wrote in #note-8:

Thinking through the desired behavior of a pinned drawer, I would assume that tapping a bookmark should open that bookmark in the current tab and close the drawer, but long-pressing a bookmark should open it in a new background tab while keeping the drawer open. The drawer could be closed at any time by tapping in the background space, swiping the drawer closed, or tapping the back arrow. The drawer would stay pinned when reopened, but would revert to being unpinned when the app restarts.

Does anyone recommend a different behavior?

I'll gladly accept this resurrection of the old long press behavior -- not as straightforward as before but much better than the current setup. (The disappearance of the drawer after every single long press is extremely frustrating!) I suspect it would also be acceptable to most if not all commenters on #926 who shared my views. So it would be great to have this on one of the upcoming updates.

I too thank Andi for this excellent suggestion!

Soren Stoutner wrote in #note-14:

There are two ways to preserve settings across an app restart. The first is to use Android's Preferences system (this is what populates the Settings screen), which saves the settings in an XML file managed by the OS. The second is to use a custom SQLite database (this is what Privacy Browser uses to store bookmarks and domain settings).

Using the Settings system requires less work on the part of the developer. SQLite databases require a lot more plumbing of code. If I were to try to save this setting I would probably just add it to the Settings screen. However, I am more inclined to just make it an ephemeral UI that resets on each app start.

Thanks for the explanation. I still would love to see the pin state persisted (but I have to trust you with the implementation) :o)

In the end, it's a big step towards the previous behaviour and just one additional click for me. Thanks for considering this improvement.

Great, looking forward to testing it!

Thanks again, Andi