[xenial] Unable to load Home Assistant web interface more than once #442
Comments
|
downgrade to the same version that runs on vivid, don't use the one from the ppa |
|
Oxide downgraded to match vivid version. |
|
So, was this a bug in the newer version of Oxide then? |
|
Apparently. The vivid version is a lot better tested, since it was used for such a long time on the phones already. Xenial had a newer version of oxide in the archive, because it was also used for some things on the desktop, like the infamous amazon app. There is no reason for us to move to that version, since our version of oxide is built on a still supported lts version of chromium. And if it aint broke, don't fix it. |
|
I still experience this problem on Turbo 16.04 r47. |
|
Humm, i cannot reproduce this on my pro5. Can you try with an other "open" https page so i can try the same page as you? |
|
This is really strange, it seems this only happens with my own Home Assistant site https://[mysecretHAname].duckdns.org. I don't want to leave out that address for everybody to see even though it requires login credentials. I have tested some other https://***.duckdns.org sites and they load and reload without problems. I have also emptied the browser cache and erased the browser history and rebooted the phone, but my very own site won't render. |
|
I don't know if it is related, but I installed web telegram from the OpenStore and I now get "Oops, something went wrong! Reload the page every time I start it. Reload just makes the error reoccur. |
|
I doubt it is an https problem only. Normally crashing browser means the page was too complex. Is it using a lot of html5, floating windows, animations etc.? Or maybe it lots a ton of javascript in the background. Can you verify with http, is it possible to switch the webserver to that mode? |
|
Unfortunately I can't verify with http, as it is an encrypted webserver. There is something fishy with the xenial browser though. There are quite a few web pages that don't work properly, see attached screenshots. mtp://[usb:002,007]/Pro5%20Ubuntu%20Edition/Pictures/Screenshots/screenshot20180316_054916134.png |
|
Can you actually see those screenshots? |
|
You'll need to upload those again. Maybe store them on your disk before uploading, I don't think doing it over mtp works. |
|
Ok, forget about those. Just found the issue #423 with gsfonts. That took care of my examples above. But what about G+, that still doesn't render saying the browser is outdated or unsupported? |
|
Sounds like #88 again, we'll need to modify the user-agent exception. |
|
Could the https issue I am having with ***.duckdns.org be related to a user-agent issue? |
|
You say that the problem is just your site on duckdns. Can you reproduce this problem with reloading an HTTPS page on any other site, or just your own private site? |
|
As I recall, most of the https:// pages I have tried work ok. I have managed to reproduce it on this page though: https://www.home-assistant.io/demo |
|
It is an open source project for home automation, which is becoming increasingly popular. |
|
I run it off a Raspberry Pi. |
|
Okay, I am able to reproduce the problem on both the Nexus 5 and Fairphone 2 with the demo you linked. It seems like we're able to load the webpage once, any subsequent attempt across tab closing and opening, rebooting, or clearing cache and history causes this crash. I was able to pick this log from Looks like the browser segfaults... somehow. It all seems to be on the GNU side as logcat stays completely silent during the crash. This one's going to be fun. |
|
Thanks Dalton, good to hear it is reproduceable, hopefully also fixable. I wasn't really keen on handing out my home automation login credentials. |
UniversalSuperBox
changed the title
|
@tomoqv, Can you try accessing your Home Assistant web interface over HTTP only, or does your server always upgrade? If it does, maybe you could disable that for a short time (only on your local network) and verify again. We need to verify what data gets received by the browser before it crashes (since it's too good to give a debug log) without resorting to heavy MITM "attacks". We are also going to try downgrading Oxide in 16.04 to the Vivid version. That may fix this issue. If it does not, though, we will likely need to move this issue to a future release due to its relatively low impact but high debugging cost. |
|
The server is constantly updating sensor and time based values and displays it to the client UI. I don't think it is possible to just swap to http as my RPi is encrypted and password protected. I will seek some guidance from the Home Assistant community on the issue, although it is unlikely that I find anyone using Oxide on Ubuntu 16.04 as a client. Could you provide me with some further info on the Oxide browser, version, engine etc. in case somebody picks up the topic and starts asking me questions? If this can't be solved by any browser in xenial, it is unfortunately going to be a deal breaker for me moving to 16.04 as Home Assistant is my most important and most frequently used web app on my phone. |
|
I have opened a thread about this in the Home Assistant community. You can find it here. |
|
I have cleared both browser cache and history, but I don't even get past the login screen in Home Assistant. After clearing and restarting the browser I am not allowed to finish the url input. The OSK disappears and so does the first part of the url that I entered. |
|
You've hit #567. That should be fixed in the newest image. |
It turns out it is not #567 because the OSK crashes after entering "https://[mysecretHAname].d" when I am supposed to type "https://[mysecretHAname].duckdns.org". [mysecretHAname] does not contain any characters from the numerical keyboard. Edit: Typing the same url string in Notes, the OSK crashed in my first attempt, but reappeared after a while. After that I was able to type the entire url also in the web browser, but it crashed already on the login screen even though history as well as cache had been cleared. https://home-assistant.io/demo loads briefly before browser crashes. |
|
For me the demo page works on FP2 and 16.04. But can you try our browser experiment: https://forums.ubports.com/topic/1291/install-browser-ng-for-qtwebengine-goodness - and tell us the result? Because if this works, we will shift this ticket probably to OTA-5 where we try to release the new browser. TBF not many people reported problems like that, so I suggest to not make this an OTA-4 blocker. |
|
Hi @Flohack74, |
|
Home Assistant works with Browser Next, horray! However, I still get browser not supported by Google+. Now, all I need is a way to utilize Browser Next in webapps and I will be all set. |
|
We won't fix this in OTA-4, since we will be moving off of oxide (our own packaged version of chrome) to QtWebEngine (from upstream). See #653. An experimental browser based on that can already be installed from the OpenStore, and the QtWebEngine library can be used in apps on xenial. For reference and to avoid duplicate reports, we'll leave this issue open with the |
|
Closing since we are tracking QtWebEngine impl here #653 |
Steps to reproduce
I have a home automation system, encrypted and password protected, running off a RPi3. Loading that page in a browser tab works fine the first time, but after closing the browser or after returning from suspend I get the message:
"The rendering process for this tab has closed. Something went wrong while displaying https://[mysecretHAname].duckdns.org."
I am presented with the options "Close tab" or "Reload page". If I reload the page, the same error message repeats. If I close the tab and reopen it also the same error message.
For obvious reasons, I can't disclose the actual url, but I will try to see if I can recreate this issue with another https page.
Expected behavior
The page is expected to render upon reload.
Actual behavior
The page won't render.
Logfiles and additional information
UTdmesg.txt
UTlogcat.txt
-->
The text was updated successfully, but these errors were encountered: