Search/address bar pushes parts of the website out of the visible area of the browser window

[nabemono]

Describe the bug
When webpages are loaded in SmartCookieWeb, the search/address box/bar is always visible. This seams to push parts of the website out of the visible area of the browser window if these parts are aligned to the bottom of the assumed browser windows size. The part not visible has the size of the search/address bar of SmartCookieWeb.

To Reproduce
Steps to reproduce the behavior on a mobile phone:

1. Clear cookies (and disable Cookie blocking if enabled)
2. Load Google (optional with search terms) (or another website that positions a dialogue on the bottom of the webpage absolutely based on the calculated size of the browser window.)
3. The button to accept the data privacy statement will not be visible (first screenshot).
4. If you scroll down until the search/address bar is hidden, the button on Google will get visible (second screenshot).

So I checked with RapidTables which browser window size the webpage think it is getting. In my case (mobile phone) it is 360x568. This is correct if the search/address bar is hidden. But as long as it is visible the (visible area in the) browser window it only 360x508. Because in the example Google thinks that the window has actually a height of 568, it puts the dialogue an the bottom of these 568 which results in the button becomming not accessible.

Expected behavior
No more scrolling down (and then up again) to accept dialoges or to see elements which are put on the bottom of the browser window.
So maybe the height of the search/address bar can always be substracted from the current size of the browser window when the search/address bar is visible (as webpages should mostly only care about the width of the browser window to fit and align its content).

Screenshots (reduced to 50% size)

Buttons not visible after page is loaded:

After scrolling down:

The size:

Best regards
nabemono

[CookieJarApps]

So would you like it to work similarly to Chrome, so the web page always fills the screen, and the usable area increases when the address bar is hidden? I'll work on this feature over the next few days - thanks for letting me know about it :)

[nabemono]

Hello @CookieJarApps,

I wouldn't change the current browser behaviour with showing/hiding the search/address bar when scrolling. I think it is already really good.

My Idea after taking a look into the code (as said unfortunately my understanding is very limited):

In the BrowserActivity.kt there is a method hideActionBar() which hides the search/address bar, and a method showActionBar() which shows the search/address bar. These two methods move the WebView up and down depending on the visibility of the search/address bar (= "ActionBar").

So I would suggest when the setting android:key="fullscreen" ("Hide URL bar while scrolling") is set to true/enabled, then keep the WebView always the same hight as if the option would still be false/disabled (in this case the WebView's height is not including the hight of the ActionBar, everything is displayed, nothing is pushed out of the screen). Plus:
In the method hideActionBar() before anything else is executed, then resize the WebView's height to the size that will get free by hiding the ActionBar. So the WebView will get the hight needed when the ActionBar is hidden.
Also in showActionBar() then (here as the last thing to do) the WebView's height should be set to a height minus the ActionBar again. So when to ActionBar is visible again, everything will fit the visible screen height again.

Try to summarize:

• Standard WebView's height would always be minus the ActionBar height when the ActionBar is displayed
• When the ActionBar is about to get hidden, enlarge the WebView's height first, then move the WebView up [hideActionBar()]
• After the ActionBar got visible again and the WebView has been moved down again, shrink the WebView's heigt [showActionBar()]

The behaviour "enlarge/shrink WebView's" height can already be done by the manually enable/disable "Hide URL bar while scrolling" (android:key="fullscreen") but the goal is to still be able to hide the ActionBar. Mybe the logic behind this option can be used in hideActionBar() and showActionBar() too.

By resizing the WebView this way I hope it will not be noticeable to the user or disturb the user experience.

Best regards
nabemono

[CookieJarApps]

@nabemono thank you so much for the detailed reply :) just today I had issues with the content pushed down by the navbar being hard to access. I'll make sure to fix this for the next update.

[CookieJarApps]

Sorry that it's been a while - I'll just need a couple more days to add this

[nabemono]

Thanks for the info. As it is already a very good browser, there is no pressure.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[CookieJarApps]

Just to give you an update, I can fix this easily, but for some reason when WebView is resized, the open website gets a scrollbar instead of resizing. I'll see if there's some way to force the site to resize.

[nabemono]

Thank you for still considering this issue.

[CookieJarApps]

After working on text reflow for a bit, I had an idea about this. This is the top feature on the list of things for the next update.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Slion]

This was fixed ages ago in Fulguris. Possibly one of the first thing I fixed after forking from Lightning. It has to do with the layout definition and also the way the search bar animation is implemented, either or both I can't quite recall the details TBH.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Kita2345]

Unstale

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.