Gecko esr91 work (former "Flypig's gecko dev diary")

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 :slight_smile: 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

Another issue; pwa / webrenderibg seems to be off still
see for example

also should about:config show the settings names instead of the config entries?

I still don’t understand what PWAs are (Wikipedia didn’t help), but one thing i’m pretty sure of is that it is unrelated to Mozilla’s “webrender”. And since supposedly Firefox doesn’t support it pretty much at all (again Wikipedia - still not sure what support means) i’m not sure that page needs support for it since it works fine in desktop Firefox.

Please clarify what you mean is wrong. That looks like it always has, as far as i can tell - and more importantly not missing anything obvious compared to the desktop version.

1 Like

What I can say is; with the new esr91 i got “a new version has been released refresh to install it” on the given website. I also know that the same webpage relies heavily on the webrendering functionality out of experience (i had wind overlays active on it the last time I used it from my jolla; btw even desktop firefox in fact cannot render it appropriately on my desktop debian; most likely due to the nvidia drivers having issues with the kernel updates).
I dont know where you got the association webrendering with pwa; they are not in any way related.

Interesting to know that firefox doesnt support them; thanks I learned something new :).

Okay; another issue. After the browser update, login data of microg is lost. Family link for example requires a re-login. I guess the cookies I deleted when I installed the new version?

:point_down:

    

1 Like

Unless the login process was offloaded to the browser (as in literally in the browser) that cannot possibly be related.

1 Like

I fail to see the connection ; but yes text can be confusing. :face_with_raised_eyebrow:

about the login; its the only component that changed; its on the android side and yes there is a webbased login (to google) to authenticate. On top of that, it was working 48 hours ago just fine :slight_smile:

I give up. It’s not worth trying to use logic and reason.

1 Like

Right, the “prettified” settings on desktop is actually about:preferences . Chapeau!

Dont worry, understanding users has never been easy :wink:

WebRender is disabled on purpose. That was mentioned in a blog post at some point. This is in gecko-dev/modules/libpref/init/StaticPrefList.yaml (I think that’s the place):

- name: gfx.webrender.force-disabled
  type: bool
  value: true
  mirror: once

PWA i.e. progressive web apps is its own thing and not just a flag you can flip on. According to Wikipedia, Firefox doesn’t support PWA’s on Linux (nor on Windows), and it’s only partially supported on Android. I think it’s safe to say that Firefox has to build the feature first before Browser can offer that…

What it comes to MicroG losing credentials, it is not even aware of Browser’s existence, so I’m rather certain that that was just a inconvenient coincidence.

4 Likes

Correct me if I’m wrong but I think the blog did not go into details why webrender needs to be disabled. I searched for a little while but failed to understand if it ia the future, the present or already the past in n upstream mozilla-central world

Microg perhaps not; but the process of authentication appears to have a web-based login (i.e. via browser). Not sure if the android one (which i’d expect). Could someone from jolla maybe help clarifying the flow?

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