Privacy Browser 3.0.1 has been released. This is a bugfix release to correct a couple of serious bugs in the tabbed browsing interface that couldn’t wait for 3.1. A couple of other items were also added to release because they were ready to go in time and resolved less serious bugs.
Because some people don’t want the app bar to scroll off the page, especially on tablet interfaces that are not scrunched for space, there is an option to disable app bar scrolling. However, the way I had it configured, this would disabled app bar scrolling in the WebView, but not in the app bar itself. So, if a user accidentally scrolled up on the app bar interface (for example, when trying to scroll the tab layout left or right) the app bar would scroll off the top of the screen. And there would be no way to get it back without restarting the app or going into settings and enabling app bar scrolling. Having an important part of your interface disappear is a significant enough bug to merit an emergency release.
Similarly, when app bar scrolling was enabled, if a user had multiple tabs open, and one of them was blank (like a new tab), the app bar could be scrolled on and off the screen only on tabs that had a populated WebView, not blank tabs. So, if the user had scrolled the app bar off the screen, then opened the navigation menu by swiping from the left, then closed the tab, if the newly activated tab after the close was blank, there was no way to scroll the app bar back onto the screen. This could be remedied by loading the homepage or a bookmark, or by swiping to another populated tab (if one existed). But those options were not naturally obvious, and the user was often left feeling like the controls had been removed and they were left with a blank or crashed app. Again, interface goes missing; emergency patch release.
I received a crash log that described a rare crash that could occur when a web page finished loading. This was rare enough that I would not normally do an emergency release, but because it was an easy fix I added it into this batch.
With the 3.0 release, I received a lot of feedback, support, suggestions, and bug reports (thank you for all of them). The single most common topic regarded the closing of tabs. There is ongoing discussion about adding a close icon to each tab, which may happen sometime in the future. However, I realized I could improve the functionality of the back button as it related to the closing of tabs.
Prior to version 3.0, if Privacy Browser was at the beginning of the history list and the user pressed the back button, the command would be passed up to the Android system, which would move Privacy Browser off the screen and return either to the app that launched Privacy Browser or to the home screen. In early beta testing I realized this behavior didn’t always work well with tabbed browsing. For example, if a user had multiple tabs open and then switched to an incoming message in another app and clicked on a link in the message, Privacy Browser would reopen with the contents of the link in a new tab. After reading the web page, tapping back would return to the messaging app. This felt natural. But, if a user had been browsing with multiple tabs in Privacy Browser for an extended period of time and then hit back on one of the tabs that was at the beginning of the history view, they would be kicked out to whatever app had been running before Privacy Browser, even if it hasn’t been open for hours. This behavior felt unexpected, especially when other tabs were open. A kind of, “I wasn’t done yet, where are you going?” experience.
At the time, my solution was to make back load a blank page if the WebView was at the beginning of the history. This created a weird scenario where you could cycle between a blank page and the last website by repeatedly pressing back. However, in considering feedback I received about this behavior as well as the desire for a more readily accessible way to close tabs, I realized that, if a tab is at the beginning of the history list and back is pressed, the most natural behavior is to close the tab. This leaves Privacy Browser in the foreground if other tabs are open, resolving the unexpected behavior described in the previous paragraph. And it makes it easy to close tabs that were open via intents from other apps, which is probably about 90% of normal tab usage.
7 responses to “Privacy Browser 3.0.1”
Privacy Browser is a very impressive browser. It has been for long time, and it’s just getting better and better. The lack of tabs was the only thing that kept me from using it as my primary browser. I think the fixes in 3.0.1 will solve the issues I have noticed in 3.0, so from on I think I have a new default browser on android… 🙂
🙂
[…] one tap but closing a tab takes two (not a very symmetrical experience). Based on user feedback, in version 3.0.1 I added the ability to close a tab that is at the beginning of its WebView history using the back […]
With tabs privacy browser is now my main browser.
As to the UI….
I suggest looking at Boat Browser and Samsung internet browser. Both put commonly used UI elements in a bottom bar, Foss browser takes this another step by making the URL bar at the bottom as well — I don’t know why phone apps have everything you need to reach at the top in the most difficult of areas to reach.
Nonetheless moving this to a quickly and easily reached bottom element would minimize the UI and make common tasks quicker with less taps — examples: Samsung internet long press tab button for new tab, boat browser can have a close tab button and long press clears and exits browser, swipe on bottom toolbar to swipe tabs, etc.
The last note brings up a conflict currently with the browser’s swipe to switch tabs. It breaks web elements such as Google’s weather widget when you search for weather — any web element that uses a left or right swipe doesn’t work properly in PB 3.x.
Anyway you go, best browser still!
I’m glad you enjoy using Privacy Browser.
There is an existing feature request to have an option to move the app bar to the bottom of the screen at https://redmine.stoutner.com/issues/143. You might consider adding any comments you have there.
The problem with tabs breaking elements that scroll left and right is documented at https://redmine.stoutner.com/issues/415 and will be fixed in the 3.1 release.
Please do not move the app bar permanently to the bottom. I hate this “feature” on the FOSS-Browser most. Maybe an option in the setting, where to place this bar.
I agree with you. As described at https://redmine.stoutner.com/issues/143, if I do implement this it will be an optional configuration.