Ah, cool. I haven’t a 4.6 (well, my sony, but I don’t use that) device to test myself … Still using anglefish for daily … I wonder if it makes sense to start testing webview stuff (since I have a bunch of webview apps) … but I’m a bit hung up with my fave phones.
2 Likes
What UA are you using? Maybe that also redirects to the mobile weather page and fixes that
1 Like
The one that was already used for most pages in ua-update.json, i.e. Mozilla/5.0 (Android 8.1.0; Mobile; rv:78.0) Gecko/78.0 Firefox/78.0. Obviously the 78 here indicates it is not final.
1 Like
I’m done testing esr91 in my dev phone, so I installed in my daily driver today! Browser works fine and so does email, those cover the critical things for me!
I did, however, find a page that causes memory leak of around 30MB/s – gigantti.fi. The page displays mostly, but it displays a “something went wrong” type of message. The browser process doesn’t close with a swipe, but requires a SIGKILL to go down, or an oom killer to snipe it. This is what gets written in console:
JavaScript warning: https://www.gigantti.fi/zKMfsN/LTkgA_/V4y/mWE/mM91Qw/5YiJkQ6S4mXb/XkczNCdR/VhR1TA/4bCx4, line 1: unreachable code after return statement
JavaScript error: https://www.gigantti.fi/_next/static/chunks/fd9d1056-914b8c2a9cccdd42.js?dpl=dpl_8p8YG9CCzKZM4aUKyfhM8aqJLHu4, line 1: Error: Minified React error #185; visit https://react.dev/errors/185 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
JavaScript error: https://www.gigantti.fi/_next/static/chunks/fd9d1056-914b8c2a9cccdd42.js?dpl=dpl_8p8YG9CCzKZM4aUKyfhM8aqJLHu4, line 1: Error: Minified React error #327; visit https://react.dev/errors/327 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
JavaScript error: https://www.gigantti.fi/_next/static/chunks/fd9d1056-914b8c2a9cccdd42.js?dpl=dpl_8p8YG9CCzKZM4aUKyfhM8aqJLHu4, line 1: Error: Minified React error #327; visit https://react.dev/errors/327 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
The first React error link expands to Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops. No clue if that’s the cause though.
Setting the user agent doesn’t help either.
On the other hand, many sites that didn’t work before now do! The browser also feels faster and smoother - overall a massive improvement! Thank you!
3 Likes
I guess that it wouldn’t be appropriate to open an issue every time a site doesn’t render properly or at all, right?
Is it of interest to know sites not working correctly? If so, where could we collect them? I have an example, but I don’t know where to put it:
2 Likes
I managed to build ESR91 for armv7h – hello from Xperia X!
However, WebView shows white screen for me, and eventually either gets SIGABRT or SIGSEGV, so there are definitely bugs to squash still!
I also used 4.6 target for this and deviated from the instructioms a bit, so there’s that, too.
Please expect bugs! confirmed 
10 Likes
Any chance i486 would work? Tablet needs so some love with it’s outdated appsupport
2 Likes
Sure, but there might be a lot of sites which don’t work correctly, and I guess it is of no use to open an issue for each site.
1 Like
I’ve been using this ESR91 for two days now and I must say it’s a huge step forward. I haven’t had any problem at all, not even the ones mentioned by others. Wikipedia, this forum, everything seem to work on my side.
Of course, I’m not very big on browsing the web on my phone, but still… it seem to work very well.
Thank you so much @flypig and everyone else who has contributed.
1 Like
I have pushing the engine quite hard as well the past 4hours or so. Indeed, it looks very promising. Thus far, I have noticed few minor glitches and nothing major. Excellent jobs @flypig !!
After we get the user-agent patch in place that should help in texture allocations (I think) and surely engine should start serving more mobile friendly pages.
9 Likes
Is there a way to opt-out? Example of wikipedia not using x vs y to trigger mobile page is pretty bad for me as prefer desktop version, on some pages getting real desktop version is a pain even with the desktop toggle on
1 Like
Usually that’s because of UA detection. I’ll build an engine with the UA fix and give a look. The embedlite-components has a swap pattern for the desktop <-> mobile swap.
Testing mobile vs desktop mode at the moment doesn’t make much sense given that the opened website actually react to the UA. More and more sites are actually reflecting other attributes that engine tells and providing results accordingly.
2 Likes
I can give it a try tomorrow. I managed to compile both armv7hl and aarch64 today, so i486 has a chance of success as well.
Thanks, I’ll create an issue for the Gigantti website issue, since that requires command line to stop the browser process from hogging all memory.
@rainemak Would you be interested in the backtraces I have from my Xperia X? I can send them to you as a dm. There’s a lot of libhybris and wayland included in them… Edit: The packages were compiled for 4.6.0.13 target which is what my device also runs.
5 Likes
Today, I used packages provided @flypig directly. Those work on without hacks on top 5.0 as well (previously I need to do some libstdc++ copying and symlinking). There are some issues but more on those issues a bit later once we get bottom them issue – currently I don’t have even backtraces of those issues.
All in all, looks very very good, I must say! Surely, @flypig knows my tests as well as we have been working on these kind of things in the past as well.
Awesome to see how you all are helping here!
5 Likes
@direc85 , it could be the same issues as I saw on one device – don’t know yet. Let’s crack first the most pressing issues regarding mobile optimization as more and more community members are commenting regarding mobile friendly sites not being served correctly.
2 Likes
Are you sure you are not just encountering the libhybris bug which was worked around by flypig? Based on at least one report that workaround is not always working and new libhybris fixes the issues.
1 Like
It looks like to be a different issue. It happens with preload too. I only get a white page and the crash occurs when I minimize the app and tap the cover to maximise it again:
> LANG=C LD_PRELOAD=/usr/lib/libhybris/eglplatform_wayland.so sailfish-qml harbour-whisperfish
[D] unknown:0 - Using Wayland-EGL
greHome from GRE_HOME:/usr/bin
libxul.so is not found, in /usr/bin/libxul.so
Created LOG for EmbedLiteTrace
[D] onUrlChanged:120 - Url changed to: https://signalcaptchas.org/registration/generate
Created LOG for EmbedLite
[D] unknown:0 - Updating services as GetServices returns
[D] unknown:0 - No default route set, services: 11
[D] unknown:0 - Selected service "xxx" path "/net/connman/service/wifi_xxx_xxx_managed_psk"
Created LOG for EmbedPrefs
Created LOG for EmbedLiteLayerManager
DLOPEN: checking eglplatform_wayland.so
DLOPEN: loading eglplatform_wayland.so
DLOPEN: loaded wl_proxy_destroy from eglplatform_wayland.so
DLOPEN: loaded eglplatform_wayland.so
[D] onUrlChanged:120 - Url changed to: https://signalcaptchas.org/registration/generate
DLOPEN: checking eglplatform_wayland.so
DLOPEN: already loaded
// Crash 1
fish: Job 1, 'LANG=C LD_PRELOAD=/usr/lib/libh…' terminated by signal SIGABRT (Abort)
// Crash 2
fish: Job 1, 'LANG=C LD_PRELOAD=/usr/lib/libh…' terminated by signal SIGSEGV (Address boundary error)
// Crash 3
sailfish-qml: ../src/wayland-client.c:2339: wl_proxy_set_queue: Assertion `proxy->display == queue->display' failed.
fish: Job 1, 'LANG=C LD_PRELOAD=/usr/lib/libh…' terminated by signal SIGABRT (Abort)
Actually, the page renders sometimes on Xperia 10 III, at least with the prefix, but it will also then crash when swiped to background and reactivated.
2 Likes
Just a half-baked update: there is a CORS error in the console. L.E. filed this bug.
The application shell was using “security.fileuri.strict_origin_policy” to overcome that.
It might be that the http server needs to be upgraded to https. I tried that with a self-signed certificate but fought another bug:
// JavaScript error: file:///usr/lib64/mozembedlite/components/EmbedLiteErrorPageHandler.js, line 162: NS_ERROR_XPC_NOT_ENOUGH_ARGS: Not enough arguments [nsICertOverrideService.rememberValidityOverride]
overrideService.rememberValidityOverride(uri.asciiHost, uri.port, cert, flags,
temporary);
The number of arguments seems to have grown with an object between port and cert as in security/manager/pki/resources/content/exceptionDialog.js from gecko dev. Or I might be wrong cause I can’t get rid of the unsigned certificate screen.
(Quest continues)
3 Likes
