REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): 4.0.1
HARDWARE (XA2, Xperia 10…): Jolla Tablet (and on fp2 Version 3.4.0)
UI LANGUAGE: german
REGRESSION: (compared to previous public release: Yes, No, ?): no
DESCRIPTION:
the jolla browser did not recognise 'https://domain:port/ as valid url.
PRECONDITIONS:
none
STEPS TO REPRODUCE:
open jolla browser
type URL with port extention
EXPECTED RESULT:
Webpage should be loaded
ACTUAL RESULT:
The URL is not valid and cannot be loaded.
ADDITIONAL INFORMATION:
(Please ALWAYS attach relevant data such as logs, screenshots, etc…)
not possibe no screenshot on tablet
I do confirm!
(another blocker to update my daily driver )
Going with well known default ports
http --> 80
https-- > 443
will work but that’s it.
If you use a different port you get above mentioned error!
(to avoid misunderstanding: of course it is not about https://forum.sailfishos.org:444 or something not available but a well reachable own server listening on a free defined port)
On SFOS 3.2.1.20 browser (and earlier) it worked/works.
Well, since one browser ‘refuses’ to connect, who knows why the other doesn’t connect. I’m not confusing anything. I’m being critical of setting up a test scenario that may cause errors that have nothing to do with port handling. But I also set up letsencrypt everywhere as a habit.
You may have noticed that some browsers have begun to limit how you enter protocol before you even enter enter?
And I said, It’s a no go on 3.4, confirming the bug report. Confusing?
It’s a selfsigned cert, so the warning is correct.
If you install the root certificate on your system (as i’ve done) the ‘Warning: Potential Security Risk Ahead’ vanish .
But anyway the error ‘… invald URL …’ is a bug.
Using a URL with ‘domain:port’ on a nextcloud account works as expected, so is is a bug on the browser handling …
Jeez, guys. I understand this. But testing software demands reducing, not increasing the complexity of the test scenario.
And I actually don’t have time to waste, so would like for the errors to be tested to be limited to those which are errors and not insufficient test scenarios.
In general that’s a good approach but to the matter at hand not relevant. We’re only cluttering the bug report… somebody gotta read this for internal tracking over at Jolla’s side. so let’s keep it dry and boring but technically relevant
Understood. So it’s the same component in 3.4 and 4 and I should stop looking at the source (for instance as a dev in the context of:SailfishOS::WebEngine)? Looks like the bug report ist for 4.0.1
On FP2 version 3.4.0 (community port) it’s the same behaviour.
I also setup a Website without ssl (port 4080) - but this is not helpfully because the the jolla Webbrowser automatically replace the http with https - the same a firefox does (this is stupid - and could not work on URLs with ‘:port’ because ssl always use an other port as nonssl …).
Google chrome did a better job here.
I found this a bit confusing since you reported for 4.0.1 but also mentioned 3.4. I tested two ports 3.4 to confirm your finding. I guess it’s a bug in the webview components that begins in 3.4 and carries on to the 4.0.1 and new gecko parts?
@poetaster, sorry for confusing you .
I’d missed to set the correct flags and did not fill the bug report for all devices i have.
The bug occurs on the following devices (as far as i cat try):
Jolla Tablet Version 4.0.1
Gemini PDA Version 4.0.1 (SaifishX from Jolla)
Fairphone 2 Version 3.4.0 (Community Port fom mal)
As @peterleinchen wrote on 3.2.1 it seems to work. So you are right - beginning with 3.4.0 there are new gecko parts and i looks like that all devices with 3.4.0 and above should have the problem.
It seems that the second problem about replacing http with https also comes with this new parts because native firefox (on my debian) also have this feature/bug.
The automatic switching from nativ (http) to ssl (https) protocol will not work on all Websites (especially on ‘privat’ Websites behind firewalls) with non standard ports.
Not really. It’s about a wrong error message. URL validation works just fine as you can see by running tcpdump before opening the browser, e.g.
tcpdump -i any -s 0 -w /tmp/dump.pcap port 4443
If you analyze the dump with wireshark, you will see the phone connecting, i.e. the URL has been properly parsed, but the TLS handshake fails. And here the browser generates a misleading error message.
On 4.0.1 and now also 4.1.0 I can reach the eierkopp and get asked for credentials.
But with self-signed certs (the one provided by gabs5807 and my own test server) I get
)
did a better job here.
.