MainUI on Vue 3: Beta testing bug reporting #3381
Replies: 20 comments 94 replies
-
|
The search field in the navbar doesn't respect dark mode: 
|
Beta Was this translation helpful? Give feedback.
-
|
Does this also occur when using the black navbar or only with the orange one? |
Beta Was this translation helpful? Give feedback.
-
|
Only with the filled one |
Beta Was this translation helpful? Give feedback.
-
|
Just fixed this, thanks for reporting. |
Beta Was this translation helpful? Give feedback.
-
|
This has nothing to do with the Vue3 upgrade, but since you're all deep in this anyway now, maybe you could give it a bit of thought: https://community.openhab.org/t/mainui-how-to-handle-http-status-204/166100 The problem is simple, the REST API responds with HTTP status 204 in situations where the answer is "empty" (ask for a list of something where there are no elements etc.). This isn't received well by MainUI since it expects a JSON payload to parse, which fails, since there's no content with a 204. I guess the "smoothest" solution would be if whatever receive the replies ( |
Beta Was this translation helpful? Give feedback.
-
|
Good thing pointing that out here. |
Beta Was this translation helpful? Give feedback.
-
|
I have added it to the to-do list. |
Beta Was this translation helpful? Give feedback.
-
|
So first off , great Job, i'm running this now and it looks great! Also is seems generally snappier , especially on some older android tablets i have been phasing out b/c the Main UI was always kinda painful on them, its actually quite useable now. My iPad minis are smoother then ever, so thats also awesome! Couple notes:
Again, awesome work. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I have also experienced that the UI feels very fast now.
Deleting node_modules is a good idea given the large changes to the dependencies. Wrt to the dependency error, I haven't experienced that myself, running on Linux x86_64. We should probably investigate this later, WDYT?
That's a regression, "old" Main UI was requesting /rest/, so thanks for catching this. I will commit a fix soon. |
Beta Was this translation helpful? Give feedback.
-
I don't see this issue as well - also running on a mac. Can you run |
Beta Was this translation helpful? Give feedback.
-
|
@digitaldan posted: Here is the complete stack trace from NPM as well as the npm list command at the end (which finds nothing). Deleting package-lock and node_modules, then running |
Beta Was this translation helpful? Give feedback.
-
|
@jsjames posted: I found this discussion regarding this. Can you try adding this as an optional dependency in package.json? "optionalDependencies": { |
Beta Was this translation helpful? Give feedback.
-
|
@digitaldan posted:
At least this time the error message is rather helpful and tells you how to fix the error, if only temporarily ! |
Beta Was this translation helpful? Give feedback.
-
config:
layoutType: fixed
fixedType: canvas
label: aaaatest
sidebar: true
blocks: []
masonry: []
grid: []
canvas:
- component: oh-canvas-layer
config: {}
slots:
default:
- component: oh-canvas-item
config:
x: 20
y: 20
h: 150
w: 200
slots:
default: []Will show: 
|
Beta Was this translation helpful? Give feedback.
-
Just submitted a fix for this, can you give it a try to make sure it works for you. |
Beta Was this translation helpful? Give feedback.
-
|
So i have noticed number inputs on lists (maybe other inputs, and not in lists, have not tested) do not work on Safari / IOS My number input for "Start a Grill Session" (its a Kamado Joe BBQ Temp control unit) How it renders on Safari (no actual number input or display on any of the input fields) How it renders on Chrome (correct) |
Beta Was this translation helpful? Give feedback.
-
|
The priority should be to make sure there are no html errors based on the framework. Any user defined type would still override an assumed type - in fact, I think having defaults here makes sense as it will eliminate additional configuration for users unless they want something different. |
Beta Was this translation helpful? Give feedback.
-
|
As I said, I'm not sure exactly under which circumstances the type is or isn't defined, or how "qualified" the guessing would be, but trying to be "too helpful" in such situations can often be a big mistake, because people don't understand why things behave like they do. Any such "algorithm guessing" should at the very least be well documented, so that users can know why things end up like they are. So, this is more of a general precaution from me, I know developers often prefer to make "some guess" to get the problems "go away", and lots of things misbehave because of this (generally). |
Beta Was this translation helpful? Give feedback.
-
|
I think assuming the type based on the item would be best as well (using text as a catch all). |
Beta Was this translation helpful? Give feedback.
-
|
I get the same error when trying to insert an "Input List Item" before I can configure it at all - so there's no Item to "assume" anything from. |
Beta Was this translation helpful? Give feedback.
-
|
Just got a new error that I think is related: Uncaught (in promise) TypeError: Cannot destructure property 'type' of 'vnode' as it is null.
at unmount (runtime-core.esm-bundler.js:5890:7)
at unmountComponent (runtime-core.esm-bundler.js:6027:7)
at unmount (runtime-core.esm-bundler.js:5922:7)
at unmountChildren (runtime-core.esm-bundler.js:6041:7)
at unmount (runtime-core.esm-bundler.js:5946:9)
at unmountChildren (runtime-core.esm-bundler.js:6041:7)
at unmount (runtime-core.esm-bundler.js:5946:9)
at unmountComponent (runtime-core.esm-bundler.js:6027:7)
at unmount (runtime-core.esm-bundler.js:5922:7)
at unmountComponent (runtime-core.esm-bundler.js:6027:7) |
Beta Was this translation helpful? Give feedback.
-
|
I just checked out the latest I don't know to which degree these are relevant or not, but it didn't use to be that many warnings and errors AFAICR: [Vue warn]: Property "forceEditMode" was accessed during render but is not defined on instance.
at <F7Tab id="design" class="layout-editor-design-tab" tab-active=true >
at <F7Tabs class="layout-editor-tabs" >
at <F7PageContent ptr=false ptrDistance=undefined ptrPreloader=true ... >
at <F7Page onPage:afterin=fn<bound onPageAfterIn> onPage:beforeout=fn<bound onPageBeforeOut> class="layout-editor" >
at <LayoutEdit key="1761933696974_6" uid="overview" f7router= Router ... >
at <F7View url="/" main=true class="safe-areas" ... >
at <F7App key=0 id="org.openhab.ui" name="openHAB" ... >
at <App>
[ECharts] Can't get DOM width or height. Please check dom.clientWidth and dom.clientHeight. They should not be 0.For example, you may need to call this in the callback of window.onload.
:8081/rest/persistence/items/CurrentPower?starttime=2025-10-30T18%3A05%3A36.079Z&endtime=2025-10-31T18%3A05%3A36.078Z&boundary=true&itemState=true:1 Failed to load resource: the server responded with a status of 400 (Bad Request)
[Vue warn]: Unhandled error during execution of watcher getter
at <OhChartComponent ref="chart" context= Object class="oh-chart-page-chart with-toolbar analyzer-chart" ... >
at <AsyncComponentWrapper ref="chart" context= Object class="oh-chart-page-chart with-toolbar analyzer-chart" ... >
at <OhChart ref="chart" class="oh-chart-page-chart with-toolbar analyzer-chart" style= Object ... >
at <OhChartPage class="analyzer-chart" key="4adf0f62ae" context= Object >
at <AsyncComponentWrapper class="analyzer-chart" key="4adf0f62ae" context= Object >
at <F7PageContent ptr=false ptrDistance=undefined ptrPreloader=true ... >
at <F7Page class="analyzer-content" >
at <Analyzer ref="analyzer" f7router= Router f7route= Object >
at <AsyncComponentWrapper ref="analyzer" f7router= Router f7route= Object >
at <F7Popup tablet-fullscreen="" backdrop=false class="analyzer-popup" ... >
at <AnalyzerPopup key="1761933935257_9" f7router= Router f7route= Object >
at <F7RoutableModals>
at <F7App key=0 id="org.openhab.ui" name="openHAB" ... >
at <App>
warn$1 @ runtime-core.esm-bundler.js:51
:8081/analyzer/?item…tem=&aggregation=:1 Uncaught (in promise) Bad Request
Error evaluating async computed property: undefined
echart localisation loading failed: NOMost of these are repeated several times. The persistence error is probably because I don't have any persistence installed - still it could be handled more gracefully? |
Beta Was this translation helpful? Give feedback.
-
|
The [ECharts] can't get DOM width or height warning is one I see too - i believe it has to do how the order of how echarts is mounted - i haven't seen that it causes any issues yet. I haven't see the forceEditMode issue yet. Can you provide your overview page yaml - i'll see if i can recreate. |
Beta Was this translation helpful? Give feedback.
-
|
This is just a testing page, so things aren't properly configured, but here it is: config:
label: Overview
blocks:
- component: oh-block
config: {}
slots:
default:
- component: oh-grid-row
config: {}
slots:
default:
- component: oh-grid-col
config: {}
slots:
default:
- component: widget:colorbands_gauge
config:
enableLCD: true
item: Mill_Stue_test_Navaerende_Kontrollsignal
- component: oh-block
config: {}
slots:
default:
- component: oh-grid-row
config: {}
slots:
default:
- component: oh-grid-col
config: {}
slots:
default:
- component: oh-list-card
config: {}
slots:
default:
- component: oh-list-item
config:
listButton: true
- component: oh-label-item
config:
item: Chromecast_App
title: App
fallbackIconToInitial: true
- component: oh-toggle-item
config:
item: CommercialLock
title: Commercial Lock Status
icon: lock
iconUseState: true
- component: oh-label-item
config:
action: options
actionItem: ControllerType
item: ControllerType
title: Controller Type
fallbackIconToInitial: true
- component: oh-label-item
config:
action: analyzer
actionAnalyzerItems:
- CurrentPower
item: CurrentPower
title: Current Power
icon: energy
- component: oh-label-item
config:
actionAnalyzerItems:
- ControlSignal
item: ControlSignal
title: Current Control Signal
icon: heating
masonry: []
grid: []
canvas: [] |
Beta Was this translation helpful? Give feedback.
-
|
This one has been there before the upgrade as well, but I was kind of hoping that it was a big in some of the components and would be gone with the upgrade. It pretty much spams my console at times, and since it prevents a setting from applying, I would think that something doesn't work as intended as a consequence: :8081/overview/:1 Blocked aria-hidden on an element because its descendant retained focus. The focus must not be hidden from assistive technology users. Avoid using aria-hidden on a focused element or its ancestor. Consider using the inert attribute instead, which will also prevent focus. For more details, see the aria-hidden section of the WAI-ARIA specification at https://w3c.github.io/aria/#aria-hidden. Element with focus: <a.link> Ancestor with aria-hidden: <div.page page-previous> |
Beta Was this translation helpful? Give feedback.
-
|
There also seems to be some router error here still. When I click "Back" from In fact I'm "trapped" inside the settings when I make the window narrow enough that the left menu disappears... |
Beta Was this translation helpful? Give feedback.
-
|
There's another weird router issue (not sure if it used to be there or not): If I navigate to |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I get this one too. I tried to debug the f7 router but gave up. |
Beta Was this translation helpful? Give feedback.
-
|
@florian-h05 You talked about router replacement/switching to Vue's router. Is that a huge job, and is it actually planned or was it just "loose thoughts"? |
Beta Was this translation helpful? Give feedback.
-
|
I think it is a pretty large job, but it was more then "loose thoughts". All the issue with F7 router really upset me, though I have no plan when to tackle this. |
Beta Was this translation helpful? Give feedback.
-
|
I'm hoping that there is some progress with taming or replacing the router (I know there are many things going on, but it's quite hard to use MainUI as the router behaves now). A thing I typically do a lot when working with/debugging bindings, is to go to I typically do this quite a lot, looking at different channels/items, while I debug things in other places, and this has always been "patchy", but now it's very hopeless. I think I need to find some other "procedure" for doing this, I'm just not sure what that should be. The reason that I do this, is that I don't bother making a layout and place the Items on a page. Using "Equipment" or "Location" might work some times, but there's usually still a lot of scrolling and looking to find the Items I'm interested in, and I might have to do some extra work to get them to show up at all (semantic model and all). I typically mass-create and delete these Items, and might be recreating the Thing frequently, so it's not really that tempting to have to do a lot of work before I can get to the point that I can see what the binding does to the Item. Which is why I've found this way "to be the least complicated route" to get to where I want to. But, when "Back" doesn't work, it isn't a "fast" way of doing it at all. |
Beta Was this translation helpful? Give feedback.
-
|
When I navigate to "Add-on Store", there are nothing in the navbar, not even a back button (although clicking where it should have been takes me back, so it might just be invisible): 
|
Beta Was this translation helpful? Give feedback.
-
|
The "Help and about" page have no title either (not sure if it used to though), but at least it has the "Back" button: 
|
Beta Was this translation helpful? Give feedback.
-
|
Missing titles fixed by #3422. |
Beta Was this translation helpful? Give feedback.
-
|
Great work everyone! I've been too busy with work to try this out until today, but this is already in really good shape. There are few minor css issues that I've seen (it'll take a bit to track down whether they are my fault, so I'll report back later). The only bug I've come across so far is that clicking on a pinned item in the Developer Tools panel does not bring up the popover to change the item state.
(Also FYI: it appears that Alt + Shift + D, brings up the new Vue developer tools overlay in addition to toggling the Developer Tools panel.) |
Beta Was this translation helpful? Give feedback.
-
I just submitted a fix for this (#3418).
Yes, they share the same shortcut key and I haven't found a way to change the vueDevTools plugin shortcut. |
Beta Was this translation helpful? Give feedback.
-
|
Expanded cell contents z-index has been lost it seems:
|
Beta Was this translation helpful? Give feedback.
-
|
If the UI setting to disable card animations is set: All model cards fail to display (model pages are blank): 
|
Beta Was this translation helpful? Give feedback.
-
|
just fixed in #3421 |
Beta Was this translation helpful? Give feedback.
-
|
@florian-h05 - i have a weird error - if I bring up your emsEnergyflow widget in the widget-edit and then bring up the "set props" window, none of the labels/titles show up: 
Do you get the same on your end? I've debugged this to parameter-item / item-picker props interface and for some reason, the name of "title" as the prop name is causing issues. If I change the name of the prop to title2, things work??? |
Beta Was this translation helpful? Give feedback.
-
|
I have just checked on my phone and I have seen the issue when opening it the first time and the code editor wasn't displaying the code yet. On every subsequent try, the code was displayed immediately and the dialog showed up. But I'm not on the latest snapshot. |
Beta Was this translation helpful? Give feedback.
-
are the "titles" correct though on the items - it should be a label vs. "Item". |
Beta Was this translation helpful? Give feedback.
-
|
You are correct, it’s „Item“ everywhere instead of the labels. But that’s the case for all Item parameters for all my widgets. |
Beta Was this translation helpful? Give feedback.
-
I believe we are running into this:
I submitted a PR which will change the name of that prop to something other than title - which corrects the issue |
Beta Was this translation helpful? Give feedback.
-
|
I'm probably doing something wrong, but my Vue devtools are all acting up now. The Vue devtools didn't use to work in Firefox, so I've used Edge for Vue (don't use it for anything else, so it's otherwise "clean"). After the upgrade, it's broken. It complained that I had two versions of Vue devtools running, so I disabled the Vue 2 (6.4.0) version and enabled the "new" version (7.7.7). The little floating thing at the bottom of the screen shows up, but it's quite awkward to work with since it's just a panel that covers part of the page, and can't be "propertly controlled". When I try to open up the Edge dev tools and go to the Vue tab, everything goes wrong. All I see is the Vue "loading logo", which goes on forever. The other tabs are still functional, so it's not a "full hang", but the Vue page never loads. Further, it is no longer possible to refresh the page I'm on (but I can navigate the version that's there), and most crucially I cannot close the dev tools. Nothing happens when I try to close them, so it's pretty clear to me that the Vue tools is blocking both reload and closing. The only way to get out of this is to close the tab. The same thing happens over and over again, it's not only sometimes - it seems to be permanently broken. Does anybody have an idea why it is like this? I've quite impossible to work with now... |
Beta Was this translation helpful? Give feedback.
-
|
I'm on Windows, and the Chromium version I have is too old. Keeping Chromium updates is too much of a hassle for me with all the hoops you have to jump through. Chrome is out of the question, it's a pure spyware. That was why Edge was the "closest thing" for me, as it's here anyway, and is basically Chromium with some MS BS on top. But, something must be seriously broken. It worked fine with Vue 2. I'm wondering if this is because the "Vite tools" are configured to launch with the dev server, and that these two collide or something? Could that be? |
Beta Was this translation helpful? Give feedback.
-
|
You could try commenting out the Vue dev tools that are shipped by the Vite dev server, that setting must be somewhere in the vite TS config file. |
Beta Was this translation helpful? Give feedback.
-
|
Vue dev tools also work fine in Firefox 144.0.2 (64-bit) on Fedora 42 for me. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I haven't tried in Firefox now, so maybe that works. It's just that over time, I've gotten so used to having a dedicated browser for MainUI, and it's actually quite convenient to operate that way 😉 Since I don't use Edge and it's there anyway, it kind of fits perfectly for the job. |
Beta Was this translation helpful? Give feedback.
-
|
All the problems with the dev tools seem to have been caused by a browser bug (both Edge and Chrome(ium)): vuejs/devtools#994 However, I updated to the latest Edge, which solved the issue. That's a big relief, because it wasn't really workable as it was. |
Beta Was this translation helpful? Give feedback.
-
|
Doesn't look like the oh-knob can render at all. Any attempt to use it results in: |
Beta Was this translation helpful? Give feedback.
-
|
ah, i knew i was missing something simple, i assumed 'value' was pretty universal for vue components. |
Beta Was this translation helpful? Give feedback.
-
|
But i still don't understand then how its working for me on Chrome......... |
Beta Was this translation helpful? Give feedback.
-
|
That's....that's a good point. I wonder if the arm version of Chrome is more aggressively caching pages somehow. Your arm-based chrome is the only place it seems to work. At this point, I've tested it on mobile and desktop, difference devices different browsers and get nothing on any of them. The only thing I don't have access to is safari and you've ruled that out. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the hint, changing to :model-value="computedValue"
@update:model-value="onChange"Fixes the issue, i'll open a PR shortly after i test a bit more. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I've found a new problem, that might or might not be router-related: If I work on a widget (e.g. The browser console doesn't reveal anything of interest, it merely states: ...which I assume says something about how far the loading comes before it hangs. Eventually, the browser will inform me that "the page isn't responding", but that's after quite a long timeout. This makes it quite hard to work with widgets. Changing the address in the address bar to something "further up" than the widget address, will let the page reload, but you then have to navigate back to the widget itself. |
Beta Was this translation helpful? Give feedback.
-
If you modify the address to |
Beta Was this translation helpful? Give feedback.
-
|
This is a big one for many advanced widgets at this point: The stylesheet property is now ignored: The |
Beta Was this translation helpful? Give feedback.
-
|
Please provide the YAML to allow copy & paste. |
Beta Was this translation helpful? Give feedback.
-
|
Oh yeah, sorry about that. uid: err_stylesheet
tags: []
props:
parameters: []
parameterGroups: []
timestamp: Nov 13, 2025, 10:11:04 AM
component: f7-block
config:
stylesheet: |
.red-text {
color: red;
}
.blue-border {
border: solid 2px blue;
}
slots:
default:
- component: div
config:
class:
- blue-border
slots:
default:
- component: Label
config:
class:
- red-text
text: This should be red |
Beta Was this translation helpful? Give feedback.
-
|
FYI, I submitted a fix for this #3464 |
Beta Was this translation helpful? Give feedback.
-
|
The android app has been slow (up to 10 seconds) on many page first loads (and opening the left panel) since vue3. But now, having just updated to Build #4912 Main UI Commit e2fc3c3, the andriod app cannot open any of the administration pages. User pages will open (again with a lag), but Setting, Add-on Store, Developer Tools, and Help & About all fail to open. |
Beta Was this translation helpful? Give feedback.
-
|
I don't really know how to interpret the results of the profiler (in the dev panel), but I tried to profile a page load, and it turns out that a lot of the waiting time is waiting for It's also a bit hard to understand how processing these tags could take so long, but maybe I'm missing something. |
Beta Was this translation helpful? Give feedback.
-
Turns out I'm wrong, I just hadn't waited long enough. The administration pages will eventually open but it can take 45 seconds or more...Tested now on two different android devices. As for the delay in the main page opening, I have two cells that render trendline on their background. The pause happens before those trendlines get animated. When the pause is finished, everything jumps to completion (that is, I don't see the trendlines animate, they just appear). |
Beta Was this translation helpful? Give feedback.
-
Semantic tags processing has been rewritten, correct. Actually, the code is quite comparable to the old one, but it can be that the suboptimal code wasn't a problen on Vue 2 vs Vue 3 due to the different reactivity handling.
Using JS Array:filter and other convenience methods is slower than traditional loops, and I see another main issue. Many consecutive writes to reactive state, likely causing a ton of reactivity handling. |
Beta Was this translation helpful? Give feedback.
-
|
See #3465. |
Beta Was this translation helpful? Give feedback.
-
|
I think this (the semantic store fix) has a fair chance of being at least a part of the reason for the slowness in the Android app as well. |
Beta Was this translation helpful? Give feedback.
-
|
I don't know if this is related to the Vue 3 change or not, but I'm having some issues with the "image view". I haven't managed to figure out which component/vue file handles this, since the Vue dev tools acts like it doesn't exist (so many this is pure JS or something?), but: When I'm on So, whether this is related to Vue 3 or not, it's somewhat broken. I haven't used it much in the past, so I don't really know how it used to behave. |
Beta Was this translation helpful? Give feedback.
-
|
Testing against the album art of the demo server (demo.openhab.org, e.g. Living Room location card), the image view works, however it doesn't respect the dark mode. |
Beta Was this translation helpful? Give feedback.
-
|
When it comes to the image not showing, I've seen this on multiple occasions, but that is on "live channels" that actually change. So, maybe the "problem" there is some kind of caching, and that if the source image is "static" it won't fail? The biggest issue for me is entering and exiting the "view mode" (when the navigation bar disappears). I have no idea how to either enter or exit it willfully, I just generally have to "click around" and then suddenly it happens. If I could find the code for the image viewer, I might be able to figure out what's happening, but I haven't found it. Is that some external component? |
Beta Was this translation helpful? Give feedback.
-
|
I just found another problem that I haven't seen before - something is up with the layout in the REST API explorer: 
The "Download" button obscures the actual data, and I think it used to be a "copy to clipboard" option as well. Also, clicking at the "Download" button doesn't work, it takes me to e.g. this link: |
Beta Was this translation helpful? Give feedback.
-
That seems like only a partial fix? I assume that the download link itself will still be broken? |
Beta Was this translation helpful? Give feedback.
-
correct - i'll look at the other issue later. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think this is an issue with the new UI because I just tried with the old UI on my production server and get the same error message. @florian-h05, are you aware of a change on openhab-core that would cause this issue? |
Beta Was this translation helpful? Give feedback.
-
|
I don't know if I've ever tried to download it before, it's much more convenient to just copy. But, since copy wasn't there, download was worth a try, since the download button blocked the text itself, it was hard to select and copy the text manually. It does look weird that it has But, you're right, my production server, which is running 4.2.3, does the same thing. If download is broken, maybe it's better to just hide the button? |
Beta Was this translation helpful? Give feedback.
-
I don't think core is related to that at all. All it does provide the OpenAPI Spec on
Yes, let's hide the button. I will create a PR, which supersedes Jeff's PR for fixing the copy-to-clipboard button. |
Beta Was this translation helpful? Give feedback.
-
|
Just noticed that dayjs() does not return localised values any more. E.g., |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Please report bugs & issues with the Main UI Vue 3 Beta version here.
Beta Was this translation helpful? Give feedback.
All reactions