A minimal configuration of Main UI that reproduces this issue would be more helpful, I guess. The YAML posted above looks incomplete?
You have a 1280x750 tablet? This sounds rather ā¦ unlikely?
Well, you can even see the extra bars when youāre still in the menu (before opening any dashboard/screen). Iāll try and make pictures in both versions
As for the setting of the screen of Tallman I recognize them. The tablet is 1280x800 but if you make a gridlayout with exact this size you get scrollbars in the full screen mode. I tried all and 1275x756 was the absolute maximum to prevent scrollbars.
1 Like
Sorry my mistake, I was always using the Openhab Beta app on my tablet because I thought it was newer. I only noticed during the discussion about the changed color setting that it wasnāt like that.
Back again. Hereās the settings menu in 2.23 (fullscreen mode). As you can see the title āInstellingenā is on top of the screen. No space above it.
Same for 3.0.0 (fullscreen mode). Now thereās also in this menu a white bar present. The word āInstellingā is already lower on the sceen.
Here a sitemap with one item on 2.23
And the same sitemap on 3.0.0. Again with extra whitespace on top.
YAML for the sitemap
sitemap home_sitemap label="home_sitemap" {
Text item=gemiddeld_uur label="Dit is een item"
}
made a mistake ā¦ check again
2.23.7.beta. Also broken, so between 2.23.0 release and this one
2.23.5.beta. Also broken, so between 2.23.0 release and this one
2.23.4.beta. Working
@mueller-ma : so the bug was introduced as a part of the changes in 2.23.5.beta. That should help I think?
Well, thatās the MD3 redesign which included some changes that might be relevant which were meant for making the navigation drawer extend to full height. I just tried with my phone: everything looks fine there since in fullscreen mode I get a black bar on top to cover the notch. Iāll try this on a tablet emulator.
Well, cloned github to Android Studio and selected a 1280x800 tablet as device. Reproduces the issue on my endā¦
What API level did you use for the emulator? Nevermind, I see itās API level 29.
I can also reproduce the issue if I disable the notch handling on my device. Iāll check this.
1 Like
Yeah, Android 10 like my ārealā tablet
Turns out this statement was wrong. Whatās happening is that the action bar on top extends to cover the height of the hidden status bar (which may be OK or not, but probably rather not - but not the point here), but when showing Main UI the action bar is hidden, and in that case the web view correctly extends from top to bottom of screen. The same happens with an API level 30 emulator. Iāll also download an API 29 image when I get some time, but I suspect it wonāt behave any different.
Thus Iād like to get back to my original questions:
- does the default Main UI page also reproduce this for you?
- if not, can you get me a minimal page YAML that reproduces this?
Thatās a shame. Reproducing is step one in revolving it.
Yes, itās also present in the main UI welcome screen. The white bar is best seen above the āshadedā right edge of the menu.
But I also created a nice green screen with one label card that also reproduces the issue.
Maybe another hint. I put it on the full 1280x800. Maybe the area it scrolls now is exactly the area the white bars have āstolenā. Creating a new page/layout with this yaml produces it.
config:
label: tester
layoutType: fixed
fixedType: grid
sidebar: true
colNum: 5
screenWidth: 1280
hideNavbar: true
hideSidebarIcon: true
style:
--f7-card-bg-color: green
--f7-navbar-bg-color: green
--f7-navbar-border-color: green
--f7-page-bg-color: green
--f7-theme-color: green
screenHeight: 800
blocks: []
masonry: null
grid:
- component: oh-grid-item
config:
x: 0
y: 0
h: 2
w: 2
slots:
default:
- component: oh-label-card
config:
style:
background-color: blue
title: Hi
footer: there
slots: null
canvas: []
And last but not least, when I show this in Android studio on an emulated 1280x800 Android 10 tablet I get exact the same.
In order to check our setups. Iām running the openHAB 3.4.2 Release Build on a raspberry PI (fully updated yesterday, makes no difference).
By the way ā¦ Since you suspect itās the statusbar. What are the conditions to hide it? I donāt use it so maybe Iām missing some openHAB configuration/ special items/ things or something like that?
The āFullscreenā app setting hides status and navigation bar. Both are clearly hidden already in your case though, otherwise one would see clock, icons etc. (status bar) and buttons (navigation bar).
Ah ok, I thought some kind of openhab status bar.
Goodmorning (over here),
Well I know about Java, Android not so much. But looked at the changes in the 2.23.5-beta and the āsuspisiousā class AbstractBaseActivity (since all windows/screens suffer the problem an abstract superclass seems logic).
Killing the added code below fixes the bottom bar bug, i.e. removes it. This makes the green window go all the way down again. Of course, the code for the entire app is too big to understand in an hour. So donāt know why this was added, but itās another hint where to look. Wild guess might be that this piece of code shouldnāt be activated when fullscreen.
fun enableDrawingBehindStatusBar() {
// EdgeToEdgeUtils.applyEdgeToEdge(window, true)
// ViewCompat.setOnApplyWindowInsetsListener(findViewById(R.id.activity_content)) { view, insets ->
// view.updatePadding(bottom = insets.getInsets(WindowInsetsCompat.Type.systemBars()).bottom)
// insets
// }
}
Iāll try to find which additions introduce the top bar issue. Maybe thereās a similar one that changes the top padding.
1 Like
It was added because the activity draws behind status and navigation bar now (for the navigation drawer). Since the activity content shouldnāt draw behind the system UI, we add appropriate padding to it. GetInsets should handle the visibility, because thatās the difference to getInsetsIgnoringVisibility. Basically the expectation is for the lambda function to be called again when the system UI visibility changes.
The status bar part of this can be found in the ContentController class, because it depends on action bar visibility.
You beat me 
By disabling code below (in that class) the white topbar also dissapears.
private fun updateContentViewForInsets() {
//val i = insets?.getInsets(WindowInsetsCompat.Type.systemBars())
//val actionBarVisible = activity.supportActionBar?.isShowing() == true
//contentView.updatePadding(top = if (i != null && !actionBarVisible) i.top else 0)
}
So now the question is. If I understand you well both pieces of code is meant to position the openHab UI within the status and navigation bar of the tablet/phone. Seems weird the app must take care of this. But assuming this is normal. At least in full screen mode these are not visible anymore but the space is still created/added to prevent the openHab UI to go below them. Hence the white bars?
Maybe both pieces of code need more checking. The actionBarVisible check seems not the check enough. On my tablet/android version anyway? Maybe just an extra "|| ā¦isFullScreen() condition in both functions?
Ah, now I understand the problem this is meant to solve. Disabled full screen and yes. Now the android status/action bar are on top of the openHab UI.
So in non-full-screen setup this extra padding makes sense. So just a check āisFullScreenā to decide whether to do this or not should do the trick?
Did that, the method IsFullScreen is not working. It returns a false even when in full screen ā¦
Check my API links above. Using getInsets ought to take care of that: if fullscreen is disabled, the top inset should be the status bar height, otherwise it should be 0.