[] Regression in rendering of reCAPTCHA in sailfish-components-webview

BUILD ID = OS VERSION (Settings > About product): Koli
HARDWARE (Jolla1, Tablet, XA2,…): Xperia 10 single SIM
UI LANGUAGE: Dutch (nl)
REGRESSION: (compared to previous public release: Yes, No, ?): Yes, compared to 3.4 as confirmed by me and @gamag


The reCAPTCHA for registering with Signal does not render on SailfishOS and fails with an error when using the new and shiny sailfish-components-webview. This did work on 3.4.




  1. git clone https://github.com/black-sheep-dev/harbour-webview-example.git
  2. Change the URL:
diff --git a/qml/pages/WebViewPage.qml b/qml/pages/WebViewPage.qml
index 26f42fc..4e897b0 100644
--- a/qml/pages/WebViewPage.qml
+++ b/qml/pages/WebViewPage.qml
@@ -11,6 +11,6 @@ Page {
     WebView {
         anchors.fill: parent
         active: true
-        url: "http://www.sailfishos.org"
+        url: "https://signalcaptchas.org/registration/generate.html"
  1. Build and run the application (sfdk config target=SailfishOS- ; sfdk build and get RPMS/harbour-webview-0.1-1.armv7hl.rpm on a device).




Renders an empty page


[nemo@Sailfish ~]$ sdk-deploy-rpm /tmp/harbour-webview-0.1-1.armv7hl.rpm
Installing harbour-webview-0.1-1.armv7hl.rpm
Please confirm installation on device.
Installation successful
[nemo@Sailfish ~]$ harbour-webview
[D] unknown:0 - Using Wayland-EGL
greHome from GRE_HOME:/usr/bin
libxul.so is not found, in /usr/bin/libxul.so
1612800952037	addons.xpi	WARN	List of valid built-in add-ons could not be parsed.: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.readUTF8URI]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: resource://gre/modules/addons/XPIProvider.jsm :: _readAddons :: line 6415"  data: no] Stack trace: _readAddons()@resource://gre/modules/addons/XPIProvider.jsm:6415
Attempting load of libEGL.so
=============== Preparing offscreen rendering context ===============
JavaScript error: https://www.gstatic.com/recaptcha/releases/2Mfykwl2mlvyQZQ3PEgoH710/recaptcha__nl.js, line 441: NS_ERROR_NOT_AVAILABLE:
JavaScript error: https://www.google.com/recaptcha/api2/anchor?ar=1&k=6LedYI0UAAAAAMt8HLj4s-_2M_nYOhWMMFRGYHgY&co=aHR0cHM6Ly9zaWduYWxjYXB0Y2hhcy5vcmc6NDQz&hl=nl&v=2Mfykwl2mlvyQZQ3PEgoH710&size=invisible&cb=78evlwtvvzej, line 32: ReferenceError: recaptcha is not defined

Also tested with English locale. It does render in the SailfishOS browser (as it did on 3.4). Either a pref setting changed that I cannot find, or there’s something new in 60 ESR that I need to know about, or there’s a real regression.

I have also tested against target=SailfishOS-, with the same problem.


This is now reported, thank you.


Thank you for forwarding. Is there some upstream issue that I can track?

I asked this a few time after reporting bugs at TJC, when they were confirmed by Jolla and “filed as an internal bug at Jolla”, as did others in their bug reports.
Because consistently (over many years) Jolla never replied to that question (posed so often), IMO one shall assume the answer is “No”.

In the past many bugs were filed at bugs.merproject.org, but this is actively being (or “was”, in the meantime) phased out by Jolla. AFAIU this forum (FSO) is supposed to be the user- and developer-visible substitute for that Bugzilla instance (IMO, “sorry no, this is not a bugtracker and a forum software can never substitute a bugtracker for developers not working for Jolla!”).
Plus Jolla never explained the relationship / processes between their internal bugtracker, their public forum (TJC / FSO), the aforementioned bugs.merproject.org, the many, package-specific issue trackers at git.sailfishos.org and github.com/sailfishos/ (which should be active for a reason, as they can be switched off).

But the biggest issue is the non-visibility of the bugs and their status in Jolla’s bugtracker for developers and porters. My impression is that more than half of the community reported bugs Jolla said to have filed there never result in any publicly perceivable action (i.e., not even a “Won’t fix” message).


Captcha rendering on various native apps is not a small breakage at all, so let’s just wait for official status update.

I wasn’t aware that other apps had this breakage too; you have some pointers for me to read?

Apologies for assuming things here. I did assume that rendering Google captcha is broken at the moment using WebView, and that it affects all native apps that use it.

I can actually test this using YTplayer (Google captcha for YouTube APi access) today. I’ll report back later.

1 Like

@direc85 I’m interested in hearing whether YTplayer is affected, please do let us know!

Okay, I remembered only half wrong… YTplayer does use Google OAuth, but it doesn’t use captcha. So while I could log in, captcha was never shown in the first place. Sorry about my false assumptions.

1 Like