MobileHTMLviewer not loading page

In an Android App, I have to show a webpage using a URL that has the following structure:

https://sub.bot.domain.com/#/2

(This is not the actual domain, as I can’t share that)

When I load that URL into the MobileHTMLviewer using HTMLViewer1.LoadURL(“https://sub.bot.domain.com/#/2”) it fails with a 404 error
When I load the same URL in any browser or in an iOS project using MobileHTMLviewer, it loads just fine.

Any suggestions on how to make this URL load within the Android App using MobileHTMLviewer?

I know I can just use system.GotoURL, but I would prefer to stay within the app and keep the URL hidden.

I’m willing to share the actual URL in a DM

Please add the UnhandledException handler to your App object:

System.DebugLog(exc.Message)

What does your messages panel show? Could be related e.g. to JavaScript things.

There are no unhandled exceptions, just the 404 Error.

MobileHTMLViewer.LoadURL just passes through to the Android loadURL method, so offhand I’m not sure what could be causing your issue. If you want to create a private Issue with the specifics, I can try it here to see if there might be something in the log that can shed some light on the problem.

Thanks Paul, I will create a private issue.
As the iOS app is handling the same URL fine, my guess this is an Android specific issue.

What happens if you try loading the page in the web browser on the phone, just as a test. If it still says 404 then your web server is blocking the network the Android phone is connected to.

If you have control over the server you could look in the error log to see what URL the Xojo Android app ends up actually requesting.

I’d be curious what MobileHTMLViewer is sending as a user-agent

I already tried setting a different user agent through declares and javascript, but that had no effect.

@Ian_Kennedy : when I load the same URL in any android browser, it loads just fine without an error

@Tim_Parnell : Thank Tim, I already asked the provider of the URL to check if they could make changes so that it works in an Android Webview.

I don’t suppose it is redirecting and the HTMLViewer doesn’t for some reason?

I suspect the # is causing the problem. # is supposed to be locate a tag somewhere on the page. I don’t even think it gets passed to the server in HTMLViewer. If you can look at the server logs is the # there? I have a bug report about a similar issue:

DesktopHMTLViewer fails to load pages when # and ? are involved.
https://tracker.xojo.com/xojoinc/xojo/-/issues/78086

Just looked at that case, I’m pretty sure that # needs to be percent encoded as %23 there.

So it’s basically AZ , az , 09 , - , . , _ , ~ , ! , $ , & , ' , ( , ) , * , + , , , ; , = , : , @ , as well as % that must be followed by two hexadecimal digits. Any other character/byte needs to be encoded using the percent-encoding.

The hash is actually used by the browser to scroll to an anchor and is not part of the url that is sent to the server.

I have asked the owner of the server to check their logs, but haven’t gotten a reply yet

When I use %23 instead of #, I get “Cannot GET /%23/2” as a reply in the HTMLviewer

I understand, but unless what you’re saying is that everything after the # is meant to be part of the anchor, the euse of a # in the middle of a url is forbidden by that RFC.

Now… it could be that their intention is for the url to be

https://sub.bot.domain.com/

With the anchor being

#/2

But that too is malformed I believe. IIRC the stuff that’s part of the anchor needs to be percent encoded as well which would mean that the / needs to be encoded:

https://sub.bot.domain.com/#%2F2

I’m grasping at straws but your url is clearly malformed…

Oh duh… is it possible that # is meant to be replaced by something? Like an api number?

I appreciate your attempts Greg, but the URL is correct for a HTMLviewer on iOS and in a browser, and no matter how I encode the #/2 it fails to load the page.
The company running the server will have to look into why it’s failing. For now, as a temporary workaround I’m using a system.loadURL instead.

Other web application frameworks use this system to put “paths” after the # that are internal to the application. The one that I can safely talk about is Jellyfin, which is .NET Core framework. There are other applications that I use that do this as well, but they are a little more sensitive so I cannot talk about them.

Here’s an example URL that works just fine on my Android in Firefox:
http://localhostname:8096/web/index.html#/dashboard/users

If Android web viewers weren’t able to handle this type of URL I’m sure far more people would have noticed by now.

@Boudewijn_Krijger that’s why I want to know what the server is getting as a request. I’d like to see how the URL is getting mangled and perhaps from there we can determine what aspect of the toolchain is doing the mangling.

Edit: Added sample URL

2 Likes