ioBroker / ioBroker.vis

Visualisation for ioBroker platform.
MIT License
302 stars 70 forks source link

view not loaded after update to v1.5.4 #815

Open 150d opened 7 months ago

150d commented 7 months ago

After the update v1.4.16 -> v1.5.4 my view is no longer loaded on an older Android device (v4.4.4). Other devices (with newer Android versions) keep showing their view.

On the device in question, the "reload animation" never completes. After adapter downgrade back to v1.4.16, the view is shown again.

Versions:

Can this be fixed?

Apollon77 commented 7 months ago

Is there any chance to get infos from an error console to see the reevant javascropt error?

Apollon77 commented 7 months ago

Can you try other versions in between the range to maybe know between which versions it broke?

150d commented 7 months ago

I can't get a console, but will try the other versions.

In the meantime: Could it be this issue from way before again?

https://github.com/ioBroker/ioBroker.vis/issues/424

BenAhrdt commented 7 months ago

Downgrade to 1.5.1 => Everything works fine

mcm1957 commented 7 months ago

Downgrade to 1.5.1 => Everything works fine

As lo g as you do not try to install vis 1.5.1 at a system without any vis installed...

oweitman commented 7 months ago

which android version?

on mobile OS the apps can normaly only use one system wide webview component. for example also chrom on ios have to use the apple webview component that is safari. the same on android. the webview component is normaly chrome. https://en.wikipedia.org/wiki/WebView

Till android 4.4 kitkat, the webview is part of the system and can only be updated together with the android os. From android 5 lollipop , the webview is seperate updateable. but maybe there are some limitation from the hardware or dependency for an higher android version. if you have android <=4.4 then please look for an alternative os replacement

if you check the following comparison then you see, that android 4.4 do not or only partial support ES6 that contains important javascript extention that is used in browsers since 2015 https://caniuse.com/?compare=android+4.4.3-4.4.4,android+119&compareCats=all

if someone want realy backwards compatibility for such old versions, then they (vis) can use babel to translate the unsupported features with the help of polyfills

https://www.heise.de/blog/Babel-Runtime-Polyfill-was-wann-4225757.html

BenAhrdt commented 7 months ago

iOS

150d commented 7 months ago

I can confirm that with vis version v1.5.1 everything is back to normal. Only v1.5.4 didn't work for my device.

The device in question is a Samsung Galaxy S2 running Android v4.4.4. Even if I could find a more current custom ROM, updating Samsung devices always is somewhat of a challenge, especially the old ones...

Let's put it this way:

If the problem can be fixed in vis, I'd very much appreciate it. If it can't, or if it would be a major inconvenience for all eternity (of vis's existence), then never mind and I'll adios the device.

Apollon77 commented 7 months ago

Then we need to check all commits ... we had such effects earlier ... the reason was that "newer" Javascript language features were used that were not supported by older versions.

my guess would be the unicode Regex introduced by @oweitman ... https://github.com/ioBroker/ioBroker.vis/commit/2cc7eb526c2fb38ae142aa907dbc384d65e8d459#diff-74123207c6f7493c5a21d46b73aa56416f0f03a431a0a087c0927a14fcda10ebR126 ...

I remember from the past that such regex change generated somparable issues earlier.

https://caniuse.com/mdn-javascript_builtins_regexp_unicode ... could that match???

oweitman commented 7 months ago

hm, maybe yes

If we are talking about Android 4.4.4, then the browser version is from 2013/2014. back then there was no es6 I have already written something about this above here.

I tried the babel repl and had it translated to es2015 - but I haven't tested it yet to see whether it still works in a modern browser.

parts[u].trim().match(/^[0-9A-Z_a-z]+:[\t-\r \xA0\u1680\u2000-\u200A\u2028\u2029\u202F\u205F\u3000\ uFEFF]?[ !#-&\(\)\+\--/:=@LN\^_dlpu\{-~]+$/);

If that doesn't work, then we would have to decide how compatible we should make the part. You could still leave the old regex for ancient browsers, then data points with special characters won't work.

This code not only affects vis1, but is also included in vis2 (although, despite my advice, it has not yet been implemented correctly in all places)

In my opinion we should have a bit of backwards compatibility in the browser. but whether it has to be 10 years. From Android 5 onwards, the webview component could be updated separately

Apollon77 commented 7 months ago

I think vis2 deprecated stheseold devices anyway (@GermanBluefox right?)

oweitman commented 7 months ago

not necessarily, with the help of babel (which react uses) and polyfills, the original sources can also be automatically transformed into javascript of earlier versions. This means that old browsers can also benefit from new features, but also current browsers can benefit from future planned features that are currently in some kind of proposal stage for standardization. However, the performance is then limited because these polyfills are always normal javascript and were not implemented in C/Rust or other programming languages directly in the browser/node.

an example for the problematic regex, compatible with all browsers since 2015 (see targets field)

https://babeljs.io/repl#?browsers=since%202015&build=&builtIns=false&corejs=false&spec=false&loose=false&code_lz=A4QwTgLgzg2grgXQHQTASwLYAoCUSMgQDGAFlgPQB6MAOgCY0DuA-ggNQBcNUA_DALRJm5AAQcAhAGIAJAFIAZLjYBeAAKUA3gF8APgD8awDQBkANlsMm4FowDk6W9tPJwcAbgBQQA&debug=false&forceAllTransforms=false&modules=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=script&lineWrap=true&presets=env&prettier=true&targets=&version=7.23.6&externalPlugins=&assumptions=%7B%7D

marcel293 commented 6 months ago

I can confirm that with vis version v1.5.1 everything is back to normal. Only v1.5.4 didn't work for my device.

Downgrade to 1.5.1. helped me too. Use the VIS (embedded as iFrame) on a Raspberry 3B+ with Raspbian Stretch.

oweitman commented 6 months ago

@marcel293 @150d and what browser version? is it possible to upgrade the browser?

this discussion is about to support outdated hardware, software

150d commented 6 months ago

@oweitman I'm using the app "Wallpanel" - a dedicated, "kiosk-like" browser especially designed for smarthome purposes.

In the meantime, I was able to upgrade the device to Android 11. With this client version (and still the same browser app), as expected, the display problems with vis v1.5.4 are gone.

I tend to agree that there may be more important issues to spend development effort on than working around ancient device deficiencies. I suggest officially declaring this as a prerequisite for vis (maybe it already is and I've just overlooked it) and close the issue.

marcel293 commented 6 months ago

@marcel293 @150d and what browser version? is it possible to upgrade the browser?

@oweitman I upgraded the chromium browser (integrated in mirr.os 0.75) and it worked with vis 1.5.4. Thx for the advise.

oweitman commented 6 months ago

Why such old version Actual Version of Mirr.os 1.11.3

mcm1957 commented 6 months ago

As far as I read here label BUG should be removed as problems are caused by (very) old browsers.

Eventually this issue could be closed unless it should be kept open until some notice about required briwser version made its way to readme.

150d commented 6 months ago

This may also be an opportunity for a strategic decision: As I understand it, vis-2 is already well on the horizon (though still not in stable repository yet.) Therefore:

a) vis-1 could be kept compatible to old and very old clients in contrast to vis-2, which would make it a "fallback" solution for the future instead of sunsetting it altogether.

or

b) The browser version prerequisite could be officially declared and not be fixed. In this case, there wouldn't be very much point in keeping vis-1 alive once vis-2 is well established, since both versions would have identical client requirements.

marcel293 commented 6 months ago

Why such old version Actual Version of Mirr.os 1.11.3

Over the years, a collection of mirr.os 0.75 , HTML snippets and ioBroker VIS has been created. This "own construction" does not work with mirr.os ONE.

unsermanninchina commented 6 months ago

I am not sure if my problem is related to the bug discussed here but it looks similar.

As described here vis edit and index were not loading. But the OSes are not the same. I am running an uptodate iobroker with Debian Linux, Node.js: v18.19.0, NPM: 10.2.3, Admin is version 6.12.0.

On my Android mobile with LineageOS and Android 13 net.iobroker.vis 2.2.0 vis worked fine.

But with my laptops EndeavourOS neither index nor edit loaded, not with any browser (Firefox 121.0.1, Chrome-dev 122.0.6226.2, Konqueror 23.08.4) since some weeks. This is all most recent browser versions. I only today found time to see what might be the problem and found your discussion and that downgrading to vis@1.5.1 worked for me.

If you want me to do any tests let me know. Thank you!

elek76 commented 3 months ago

I can confirm the issue with up-to-date Windows-based browsers.

On two of my PCs, MS Edge 123.0.2420.65 shows the same behavior. One one of these two PCs, Opera One 109.0.5097.35 (with Chromium 123.0.6312.59), too. On the other PC, Opera One 108.0.5067.29 (with Chromium 122.0.6261.112) works. UPDATE: on this same PC, after update to the same Opera version as the other PC (109.0.5097.35) -> still working

Console log from one of the Edge instances (the consoles show the same errors in all non-working browsers): edge-console.log

My setup:

UPDATE 2: Both of the mentioned PCs was running Windows 10. Today I updated one of them to Windows 11. There is no change in Edge (which can expected because win10 and in win11 seem to contain the same MS Edge version).

oweitman commented 1 month ago

also irgendwas stimmt mit dem repo nicht. ich habe definitiv die Änderung im iobroker/vis repo gemacht. oben steht nun oweitman added a commit to oweitman/ioBroker.vis-2 that referenced this issue 2 minutes ago

mcm1957 commented 1 month ago

@oweitman

Nö mit dem Repo passt schon alles. Du hast auch hier einen PR erstellt wie du leicht prüfen kannst (#845). Nur arbeitest du offensichtlich nicht auf einem Fork von ioBroker.vis sondern auf einem Fork von ioBroker.vis-2 welches selbst ein Fork von ioBroker.vis ist. Schau mal genau was oben steht: commit to oweitman/ioBroker.vis-2.

Wenn du was an vis (1) ändern willst, solltest du besser einen direkten fork von ioBroker.vis benutzen. vis-2 hat soich ein wenig von vis entfernt und ist mittlerweile ein selbständiger Adapter.

oweitman commented 1 month ago

ich habe die Änderung direkt in github gemacht. im vis repo pr wird auch bei vis angezeigt.

beim ersten versuch einen direkten fork zu machen, hat er gemeckert und hat mir gezeigt, das ich schon einen vis-2 fork habe. obwohl ich bei vis war

image

image

mcm1957 commented 1 month ago

Ja, weil vis-2 eben ein fork von vis ist. Und damit ist dein Fork von vi-2 auch ein Fork von vis. Ist also alles OK und normal.

Aber das Thema ist für diese Issue wohl OT.

oweitman commented 1 month ago

ich kann kein fork von vis machen, solange ich einen offenen vis-2 PR habe