MainUI on Vue 3: Beta testing bug reporting #3381
Replies: 26 comments 170 replies
This comment has been hidden.
This comment has been hidden.
|
Does this also occur when using the black navbar or only with the orange one? |
|
Only with the filled one |
|
Just fixed this, thanks for reporting. |
|
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 ( |
|
Good thing pointing that out here. |
|
I have added it to the to-do list. |
This comment has been hidden.
This comment has been hidden.
|
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. |
I don't see this issue as well - also running on a mac. Can you run |
|
@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 |
|
@jsjames posted: I found this discussion regarding this. Can you try adding this as an optional dependency in package.json? "optionalDependencies": { |
|
@digitaldan posted:
At least this time the error message is rather helpful and tells you how to fix the error, if only temporarily ! |
This comment has been hidden.
This comment has been hidden.
Just submitted a fix for this, can you give it a try to make sure it works for you. |
|
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) |
|
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. |
|
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). |
|
I think assuming the type based on the item would be best as well (using text as a catch all). |
|
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. |
|
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) |
|
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? |
|
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. |
|
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: [] |
|
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> |
|
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... |
|
Yeah, I get this one too. I tried to debug the f7 router but gave up. |
|
@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"? |
|
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. |
|
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. |
|
Replacing the router won't be an easy task, I will first try fixing it. |
This comment has been hidden.
This comment has been hidden.
|
The "Help and about" page have no title either (not sure if it used to though), but at least it has the "Back" button: 
|
This comment has been hidden.
This comment has been hidden.
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. |
This comment has been hidden.
This comment has been hidden.
|
Can you please provide code to reproduce that? |
This comment has been hidden.
This comment has been hidden.
|
just fixed in #3421 |
This comment has been hidden.
This comment has been hidden.
|
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. |
are the "titles" correct though on the items - it should be a label vs. "Item". |
|
You are correct, it’s „Item“ everywhere instead of the labels. But that’s the case for all Item parameters for all my widgets. |
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 |
This comment has been hidden.
This comment has been hidden.
|
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? |
|
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. |
|
Vue dev tools also work fine in Firefox 144.0.2 (64-bit) on Fedora 42 for me. |
|
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. |
|
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. |
This comment has been hidden.
This comment has been hidden.
|
ah, i knew i was missing something simple, i assumed 'value' was pretty universal for vue components. |
|
But i still don't understand then how its working for me on Chrome......... |
|
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. |
|
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. |
|
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. |
|
I feel like this is "at the core" of the router bug, it seems to be possible to achieve in many different locations. Basically, it doesn't load the page the address dictates, so while the address says |
|
I have a draft PR to evaluate further that is avout the connection between the router and the browser history, probably this one helps there. |
|
I just discovered yet another "router issue". If you open a rule, click "Add trigger" -> "Item Event" -> Pick and Item -> ...and then try to cancel/go back, you're trapped in that page whether you click "OK" or "Cancel". 
|
|
Not everything is a router issue ... this time its our fault. |
The reason I assumed so, is that I've fought with something router related here in the past - where clicking "Cancel" would mess up the history. But, it's good if it's not the router 👍 |
This comment has been hidden.
This comment has been hidden.
|
Please provide the YAML to allow copy & paste. |
|
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 |
|
FYI, I submitted a fix for this #3464 |
|
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. |
|
@JustinGeorgi - when you experience the slow-down, do you see that in connecting to myopenhab.org? On the iOS app, it is very slow loading the initial page through myopenhab.org. However, with Safari, I get very reasonable performance to myopenhab.org. I submitted an issue (openhab/openhab-ios#1006) for the iOS app - curious if there could be some interaction issue between the app and the myopenhab.org servers? |
I usually just build a version and put it on my production server. |
I don't have a problem getting OH running with the updated UI, I'm just not sure if the mobile application simply acts as a web browser, or if there should be a different version of that as well. |
I don't use myopenhab.org, but I see the same behavior whether I'm on my local network or tunneling in. The screen cap I shared was while connected locally. |
|
I did a test from an Android 14 emulator against a build with the latest version of MainUI. The version of the OH application is whatever is a Google Play. The emulator itself is very slow and laggy, and loading the front page took some time, but I don't think going to "Settings" was that slow. It might depend on the content of the installation, mine is "sparsely populated". |
|
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. |
|
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. |
|
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? |
|
Can you please open a dedicated issue for this and ping me there? Provide a screenshot of the issue as well. |
This comment has been hidden.
This comment has been hidden.
That seems like only a partial fix? I assume that the download link itself will still be broken? |
correct - i'll look at the other issue later. |
|
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? |
|
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? |
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. |
This comment has been hidden.
This comment has been hidden.
|
Yes, it's possible to do this, but that would require logic in various places, which is what I at least expects is too much hassle for most projects to handle. If I remember correctly, the next version of echarts has the same thing. Everything that wants to "align with Android" mostly do this. In general, I at least, am used to this being broken "everywhere". |
|
Okay, then it would be best to fix it at dayjs. |
@Nadahar - when you say we have to add logic in various places, are you referring to multiple places in the main ui? If we add a patch to dayjs, it will be only for the main UI (unless the patch is submitted as a PR to the dayjs github, but I noticed there is not much activity there - so i doubt it would get committed). As @florian-h05 mentioned, for the main UI, we'd just need to add a line of code in a single location. |
I meant generally, to handle Norwegian, one would have to add logic in various places. dayjs isn't the only place where this is the case, as I said, I think it's the same for echarts itself, and I'm sure many other components. I don't think dayjs would want to "fix" it, since they probably don't consider it wrong, because using So, go ahead and do it centrally for dayjs, that's fine. I was just saying that generally, I don't bother to "do anything" about this issue when I come across it, because it's quite widespread, and it's not a "bug" per se, but the result of a stupid decisions made by Google (which, to their defense, probably knew nothing about the underlying stupidity of this issue - which all boils down to that the "New Norwegian" fanatics didn't like that what they call "Bokmål" was referred to as Norwegian). |
|
So we will add a conversion from See #3504. |
This comment has been hidden.
This comment has been hidden.
|
You mean the navbar is not colorized, only when scrolling down? |
|
Yes, it turns out that it appears if I scroll down. A feature almost indistinguishable from a bug 😝 |
This comment has been hidden.
This comment has been hidden.
|
Start page is not set in the app (if I set it to |
|
Without setting this the issue occurs? |
Yes
If the error is not limeted to me (as you wrote you couldn't reproduce it), this would probably be the easiest solution, I think. |
|
I get the same in the ios app. I have the default path set to /overview/, however the app seems to remove the trailing /. I do think both /overview/ and /overview should go to the same place. |
|
#3540 redirects /overview to /overview/. |
This comment has been hidden.
This comment has been hidden.
|
Which platform? Haven’t noticed this … |
|
I see the same issue on chrome - its this line in the app.styl: max-width calc(100% - var(--f7-navbar-inner-padding-left) - 140px - var(--f7-navbar-inner-padding-right)) If we remove the 140px, it fixes the issue. Any idea why the 140px was there? I can submit a PR if we are know we can remove. |
|
I have no idea where this came from - maybe it "made sense" with the older F7 style? |
|
Fixed #3530 |
|
@florian-h05 on Safari on Mac or our Native IOS app, back functionality is broken when on the "Help & About" Section |
|
Its intermittent , sometimes it works , sometime it does not. On desktop safari it seems to work more often , on IOS , at least for me it never does. I can try to debug, i guess my first step is trying to add some logging to the router when that is clicked to understand what its suppose to be doing ? I'm building the bundle from HEAD -> main |
|
So i added a bit of logging. console.debug('Backing up from', props.backLinkUrl)
if (props.backLinkUrl) return
if (props.backLinkUrl === null) {
emit('back')
return
}
const f7router : Router.Router = props.f7router || f7.views.main.router
console.debug("current path:", f7router.currentRoute.path)
for (let i = f7router.history.length - 1; i >= 0; i--) {
console.debug('History entry:', f7router.history[i])
}
f7router.back()If i load the app in IOS and the very first thing i do is click on "help and about", then try and go back i get this output, but the app does not navigate If i click somewhere else in the app (like to the overview page) then click on "help and about" and try going back , it works In the first case i tried removing |
|
Can this be related to the |
I think it is related, if i put in the base URL into Safari, like if i enter in |
|
Also if i enter |
|
In any of the editor panes (widgets, rules, configs) ctrl + f now brings up a search and replace panel at the bottom of the screen (which is cool). However, clicking anywhere on that panel closes it again instead of interacting with the elements on the panel. For example, you cannot select the regex option by clicking on it. The panel works for all of its functions if you navigate by tabbing, but not clicking. (Build #4991) Also related (though I don't know if this is a bug or not), ctrl + f is completely captured by this function. In many websites with custom search boxes like this a second ctrl + f will close the custom box and bring up the browser search function. That is not true with this search box. |
|
Overriding the browser search is a really nasty thing to do, and it should at the very least "forward it" to the browser on the second Ctrl + F. |
|
@ALL Can you please report bugs from now on using issues (as usual), I think with two milestones including based on Vue 3 we have left the beta phase. Issues allow for easier tracking than GitHub discussions. |
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.
All reactions