Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

view not loaded after update to v1.5.4 #815

Open
150d opened this issue Dec 16, 2023 · 22 comments
Open

view not loaded after update to v1.5.4 #815

150d opened this issue Dec 16, 2023 · 22 comments
Labels

Comments

@150d
Copy link

150d commented Dec 16, 2023

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:

  • Adapter version: v1.4.16 -> v1.5.4
  • JS-Controller version: v5.0.17
  • Node version: v18.19.0
  • Operating system: ubuntu (Server), Android (client)

Can this be fixed?

@Apollon77
Copy link
Collaborator

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

@Apollon77
Copy link
Collaborator

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

@150d
Copy link
Author

150d commented Dec 18, 2023

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

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

#424

@BenAhrdt
Copy link

Downgrade to 1.5.1 => Everything works fine

@mcm1957
Copy link
Contributor

mcm1957 commented Dec 20, 2023

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
Copy link
Contributor

oweitman commented Dec 20, 2023

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
Copy link

iOS

@150d
Copy link
Author

150d commented Dec 20, 2023

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
Copy link
Collaborator

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 ... 2cc7eb5#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
Copy link
Contributor

oweitman commented Dec 25, 2023

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
Copy link
Collaborator

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

@oweitman
Copy link
Contributor

oweitman commented Dec 26, 2023

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
Copy link

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
Copy link
Contributor

oweitman commented Dec 31, 2023

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

this discussion is about to support outdated hardware, software

@150d
Copy link
Author

150d commented Dec 31, 2023

@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
Copy link

@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.

  • old chromium version: 60.0.3112.89-0ubuntu0.14.04.1.1010+1
  • newer chromium version: 72.0.3626.121-0+rpt4 armhf

@oweitman
Copy link
Contributor

oweitman commented Jan 1, 2024

Why such old version
Actual Version of Mirr.os 1.11.3

@mcm1957
Copy link
Contributor

mcm1957 commented Jan 1, 2024

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
Copy link
Author

150d commented Jan 1, 2024

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
Copy link

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
Copy link

unsermanninchina commented Jan 12, 2024

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
Copy link

elek76 commented Apr 2, 2024

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:

  • ioBroker running on a Synology NAS, buanet/iobroker image v8.1.0
  • Update vis from @1.4.16 to @1.5.4
  • Node.js 18.17.1
  • JS-controller 4.0.23

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants