I don’t think they mean to day webrender in particular; just say that web [space] rendering in general is still not 100% up to the latest standards, which is to be expected (ESR91 is 3 years after all). They just sprinkle in some stuff like web[nospace]render and PWA for no reason.
And i can assure you the native browser most definitely isn’t pulling double duty as an Android “System Webview”.
I just have the Jolla C that is on 4.6 32bit, can anyone tell me how to test the new ESR91 browser? I’m eager to try it 
@flypig your perseverance and determination really shines, it was august of last year that you began working on updating the browser, and one year later here we have the results! Amazing what Open Source and people together can do
If you read blog post 333, you will see that you have to wait.
Actually, even on my Xperia 10 III the email app crashes if an email is opened and I swipe to application switcher and then back to email. So, I think that splits the symptoms into two: the crash when switching back (this was already mentioned in the blog too) and the sailfish-qml harbour-whisperfish sometimes getting stuck on a white page (which I have to test more).
I tried to compile esr91 for i486, but I keep getting this error:
0:08.07 Creating config.status
0:08.22 Traceback (most recent call last):
0:08.22 File "/home/matti/SFOS/gecko-dev/gecko-dev/configure.py", line 226, in <module>
0:08.22 sys.exit(main(sys.argv))
0:08.22 File "/home/matti/SFOS/gecko-dev/gecko-dev/configure.py", line 80, in main
0:08.22 return config_status(config)
0:08.22 File "/home/matti/SFOS/gecko-dev/gecko-dev/configure.py", line 221, in config_status
0:08.22 return config_status(args=[], **sanitized_config)
0:08.22 File "/home/matti/SFOS/gecko-dev/gecko-dev/python/mozbuild/mozbuild/config_status.py", line 163, in config_status
0:08.22 reader = BuildReader(env)
0:08.22 File "/home/matti/SFOS/gecko-dev/gecko-dev/python/mozbuild/mozbuild/frontend/reader.py", line 891, in __init__
0:08.22 self._gyp_worker_pool = ProcessPoolExecutor(max_workers=max_workers)
0:08.22 File "/home/matti/SailfishOS/mersdk/targets/SailfishOS-devel-i486.default/usr/lib/python3.8/concurrent/futures/process.py", line 555, in __init__
0:08.22 self._call_queue = _SafeQueue(
0:08.22 File "/home/matti/SailfishOS/mersdk/targets/SailfishOS-devel-i486.default/usr/lib/python3.8/concurrent/futures/process.py", line 165, in __init__
0:08.22 super().__init__(max_size, ctx=ctx)
0:08.22 File "/home/matti/SailfishOS/mersdk/targets/SailfishOS-devel-i486.default/usr/lib/python3.8/multiprocessing/queues.py", line 42, in __init__
0:08.22 self._rlock = ctx.Lock()
0:08.22 File "/home/matti/SailfishOS/mersdk/targets/SailfishOS-devel-i486.default/usr/lib/python3.8/multiprocessing/context.py", line 68, in Lock
0:08.22 return Lock(ctx=self.get_context())
0:08.22 File "/home/matti/SailfishOS/mersdk/targets/SailfishOS-devel-i486.default/usr/lib/python3.8/multiprocessing/synchronize.py", line 162, in __init__
0:08.22 SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
0:08.22 File "/home/matti/SailfishOS/mersdk/targets/SailfishOS-devel-i486.default/usr/lib/python3.8/multiprocessing/synchronize.py", line 57, in __init__
0:08.22 sl = self._semlock = _multiprocessing.SemLock(
0:08.22 FileNotFoundError: [Errno 2] No such file or directory
Error running mach:
['build', '-j1']
The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.
You can invoke |./mach busted| to check if this issue is already on file. If it
isn't, please use |./mach busted file build| to report it. If |./mach busted| is
misbehaving, you can also inspect the dependencies of bug 1543241.
If filing a bug, please include the full output of mach, including this error
message.
The details of the failure are as follows:
Exception: Process executed with non-0 exit code 1: ['/usr/bin/python3', '/home/matti/SFOS/gecko-dev/gecko-dev/configure.py']
File "/home/matti/SFOS/gecko-dev/gecko-dev/python/mozbuild/mozbuild/build_commands.py", line 153, in build
return driver.build(
File "/home/matti/SFOS/gecko-dev/gecko-dev/python/mozbuild/mozbuild/controller/building.py", line 1144, in build
config_rc = self.configure(
File "/home/matti/SFOS/gecko-dev/gecko-dev/python/mozbuild/mozbuild/controller/building.py", line 1528, in configure
status = self._run_command_in_objdir(
File "/home/matti/SFOS/gecko-dev/gecko-dev/python/mozbuild/mozbuild/base.py", line 845, in _run_command_in_objdir
return self.run_process(cwd=self.topobjdir, **args)
File "/home/matti/SFOS/gecko-dev/gecko-dev/python/mach/mach/mixin/process.py", line 176, in run_process
raise Exception(
error: Bad exit status from /var/tmp/rpm-tmp.GnHmHB (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.GnHmHB (%build)
It seems i486 target is somehow different for multiprocessing than armv7hl and aarch64, but I’m not a Python expert so I can’t really dig deeper. Searching for the error revealed some bugs, most unresolved…
Thanks for trying the build for x86 @direc85. It looks like you’re hitting a longstanding ‘Semaphore’ issue in the build engine. If so, you’ll need to make the following change (or possibly remove it, I forget which way around it is just now) to the scratchbox2 code in the engine (not the target):
This is only needed for i486 builds and will break armv7hl or aarch64 builds, so you’ll need to revert it back again if you want to switch targets. If I recall correctly this change is only needed for local builds, not on OBS.
Concerning the email app crashing when you swipe in and out of the homepage, I think @mal is right that this is the same underlying libhybris issue and I think you’re probably right to split this into separate issues.
For completeness (for the benefit of anyone who isn’t following the blog quite as closely as you are!), it looks like the email crash will be fixed by the brilliant work of @krnlyng, @mal and @affe_null as can be seen from this discussion on GitHub.
Thanks for pointing me to that commit, I added the lines to the lua file and I’ve now compiled esr91 for i486! While the esr78 starts and runs fine on the emulator, the esr91 does not. There’s no eglplatform_wayland.so, so it fails to load the file and fails an assert (log heavily truncated):
[W] unknown:0 - QWaylandGLContext::makeCurrent: eglError: 3008, this: 0x1d58750
DLOPEN: checking eglplatform_wayland.so
DLOPEN: loading eglplatform_wayland.so
DLOPEN: error loading eglplatform_wayland.so
sailfish-browser: ../src/wayland-client.c:2339: wl_proxy_set_queue: Assertion `proxy->display == queue->display' failed.
Aborted (core dumped)
Well, the good thing is that i486 compilation in itself works just fine! I’d guess there’s a patch to make it work in the emulator though…
Use the env var mentioned in the workaround to disable the preload [qtmozembed] Pre-load eglplatform_wayland.so · llewelld/qtmozembed@fb384c3 · GitHub
I managed to resolve WebView not working on my armv7hl device. It turns out the instructions on blog day 64 don’t include changes to sailfish-components-webview. After compiling and installing the resulting packages the Whisperfish captcha WebView I’ve been using as a test piece now works on my Xperia X as well - as it should have.
So, armv7hl seems to be on par with aarch64 build - crashes included.
I’m not sure about this… There’s a few seconds of delay before the white screen even gets the loading indicator. After that the captcha works well. Well, at least it seems to work reliably now.
@direc85 would you be so kind to add build instructions for the webview here? I was planning in fixing something related to the screen for temporary accepting an invalid certificate (above), and would sure appreciate if the webview would build correctly to test hydrogen. Thanks.
(L.E. Hmm maybe it’s just cloning and sfdk build -p, I did that and it didn’t hurt)
(L.E. Added webview to the build wiki)
Well, basically almost so: Progressive Web Apps for Firefox – Get this Extension for 🦊 Firefox (en-US)
According to Wikipedia, Firefox doesn’t support PWA’s on Linux (nor on Windows), and it’s only partially supported on Android.
Firefox on Android is supposed to fully support PWAs [1] and the desktop Firefox v76 to v86 had the flag browser.ssb.enabled in about:config to enable PWAs. So the code is there, but the Firefox team decided in January 2021 it does not want to care about support requests and bug reports [2] WRT PWAs and desktop Firefox.
[1]: Installing and uninstalling web apps - Progressive web apps | MDN
[2]: 1682593 - Remove the SSB feature
I think it’s safe to say that Firefox has to build the feature first before Browser can offer that…
It is all there, just not officially supported on the desktop any longer.
@attah, for a primer on PWAs see Progressive web apps | MDN.
How they are handled in practice becomes clearer reading Making PWAs installable - Progressive web apps | MDN.
Hello,
while almost never writing in this forum, I enjoy the spirit that has come up with the browser update. I read the blogpost every morning even though I didn’t understand much.
Today I wanted to test the packages provided by flypig and followed his instructions. But I didn’t get it to run. In Terminal an error shows when in this line:
$ devel-su ln -s /usr/lib64/xulrunner-qt5-91.9.1/ /usr/lib64/xulrunner-qt5-78.15.1
since on my XA2 there is no lib64 but only lib I tried the following:
$ devel-su ln -s /usr/lib/xulrunner-qt5-91.9.1/ /usr/lib/xulrunner-qt5-78.15.1
which gives no error. But after starting the browser it is still on ESR78
Probably I made a stupid error.
Yes, you did. A read error. 
The installation instruction states in point one: An aarch64 Sailfish OS phone running 4.6 (Sauna).
thanks! I suspected that - especially after the missing “lib64”. I kept just going on because a “uname -m” in terminal gave me “aarch64”. Now I know better.
EDIT:
Also I have alot of OOM crashes (?) when using outlook.com ; so this hasnt changed much from ESR 78
Evtl. Question was answered ?
Have anybody installed esr 91 on 32bit devices such xa2 or x
?
Apparently @direc85 has:
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 
I added a small PR while studying the underlying hydrogen error: rememberValidityOverride additional param by b100dian · Pull Request #101 · sailfishos/embedlite-components · GitHub
CORS error needs symbols and more debugging.
But I can no longer build locally from the final branch with patches because
2:57.40 error: failed to determine package fingerprint for build script for selectors v0.22.0 (/home/porter/gecko-dev/gecko-dev/servo/components/selectors)
2:57.40 Caused by:
2:57.40 failed to determine the most recently modified file in /home/porter/gecko-dev/gecko-dev/servo/components/selectors
2:57.40 Caused by:
2:57.40 failed to determine list of files in /home/porter/gecko-dev/gecko-dev/servo/components/selectors
This is probably something introduced by the last 5 patches (UA changes etc) but I cannot find the error to be common rust by just duckduckgoing for it…
Since Gecko 91 doesn’t announce Mobile in its useragent string, I was looking for a way to change it via about:config. According to browser - How do I change Firefox's user agent via about:config? - Super User this can be done by creating a new entry general.useragent.override
Unfortunately the UI of our web browser only allows to edit existing entries but not to add new ones.
So I added this entry manually in the file /home/defaultuser/.local/share/org.sailfishos/browser/.mozilla/prefs.js:
DON’T FORGET TO MAKE A BACKUP OF YOUR FILE prefs.js BEFORE EDITING
close / kill running instances of sailfish-browser before editing prefs.js
add this line to prefs.js:
user_pref("general.useragent.override", "Mozilla/5.0 (X11; Linux aarch64; Mobile; rv:91.0) Gecko/20100101 Firefox/91.0");
This fixes at least https://wetteronline.de showing desktop page. Switching to desktop version still works.