Difference between HtmlViewer and Browser

I built a simple streaming music player that uses the HtmlViewer to load the music stream. This has been working just fine for several years. However, a few days ago, one of the streams stopped working. It works fine if I load the stream link in any web browser, but not in the HtmlViewer. I’m trying to figure out what the difference is. I’ve even set the HtmlViewer’s useragent string to the same value as my current Firefox useragent, but it still won’t run. Any ideas why it would work in a browser, but not in HtmlViewer? Has anyone else encountered similar problems?

The stream link is:

It’s possible that they’re trying to force users to access their stream through a pay service, but I’d find that surprising because they publish all of their stream links on their website, and seem to encourage direct links. Their website is:

What version of Xojo?

Used Xojo2023r1.1, macOS Ventura 13.3.1 (a), new Desktop project, added the DesktopHTMLViewer pointed to the URL and Run. I see this:

and I can hear the music.

1 Like

Thanks for the test report. Sorry, I forgot to mention I’m using 2018r3 on a Mac. My development machine is stuck in the past because I need to use MacOS Sierra for a lot of my work.

I’ll try rebooting with a newer system and newer Xojo version, and see if that fixes it. It’s weird when the built app has been working for several years and then suddenly stops working with just one site.

I have 2018r4 here and no problems either, but can’t test MacOS Sierra, sorry.

It could be lets encrypt. Your operating system predates the new lets encrypt root certificate. You must install this to access a sizeable chunk of the modern web.

Wouldn’t that also affect a regular web browser? I have no problems with the latest version of Firefox.

Check with Safari as I guess that will use the OS certificates.

I just tried, and it doesn’t work with Safari. So it looks like the certificate is the problem. I won’t be able to test on a newer OS version until later this evening, so I’ll report back later.

Just confirmed that it works fine with a newer operating system. I didn’t have to recompile the music player app. So, the problem was MacOS 10.12 (Sierra).

Fortunately, I just finished the project that required me to run Sierra, so I can finally update.

You can also install the new ISRG root certificate on the system keychain and mark it as trusted. This should help but if you need more information search “install isrg root x1 certificate mac”

1 Like

Well, that worked fine for about 4 months, and now in the last few days, one by one, several audio streams have gone dead on my player, but still work fine when the stream URL is pasted into a browser. I tried the “dead” streams on both Firefox and Safari, and they worked there. But they don’t work in the HTMLviewer control. Of the various streams that still work on the HTMLviewer, they are a mix of https and http, and a mix of formats mp3 and m3u8. I’ve found no difference between the ones that still work and the dead ones, other than the fact that the dead ones are dead. This is what the HTMLviewer displays when a dead stream is loaded:

Otherwise it displays:

I thought maybe it was another Webkit problem, but since (I assume) Safari is using the same Webkit library, and Safari still works with the streams, then it must be some other problem.

Any ideas what I should be looking for?

It could be looking at the UserAgent and refusing to serve you data because it doesn’t recognise your ‘Browser’? Try matching it to a modern version of Safari?

Thanks Ian. That was one of the first things I thought of, and I did set the user agent to the exact same value as the version of Safari that’s running on my computer. The same Safari version that’s able to play the streams. So, the problem appears to be somewhere else.

BTW I’m building the app with Xojo 2022r1.1 which is the latest version that I have a license for. I am still running the app on an older version of MacOS: High Sierra, but since the streams work with both browsers on this OS version, I’m thinking (hoping) that the problem must be something other than the OS version.

Could it be to do with what options are specified in the heading. I’m thinking about things like “accept”.

@Robert_Weaver - have you looked in the Console to see if there are any errors shown?

I don’t think I have any control over the heading options. I’m using the HTTPViewer.LoadPage method which doesn’t appear to have this option available.

Which console are you referring to?

The Console app specifically. But there is a way to access the WebKit browser console on macOS as well.

1 Like

Thanks for that link.
Okay, I’ve added this code to enable the developer tools and call it from the main window open event.

Public Sub EnableDevTools()
  'Shell code to enable Web Devloper Tools in HTMLViewer
  Dim My_Shell As New Shell
  Dim theShellCode As String = "defaults write com.robertweaver.MyPlayer WebKitDebugDeveloperExtrasEnabled -bool YES"
  My_Shell.Execute theShellCode
  dim ercode As Integer = My_Shell.ErrorCode
  dim result As String = My_Shell.Result+EndOfLine+str(ercode)
  if ercode<>0 then 
    MsgBox "Failed to Enable Web Devloper Tools. Errcode: "+str(ercode)
    MsgBox " Success; Result: "+result
  end if
End Sub

It returns with no error, but after that I don’t know how to access the tools. The HTMLViewer doesn’t look any different.

BTW, since I’m not sure which version of Webkit is running under High Sierra, I tried both WebKitDeveloperExtras and WebKitDebugDeveloperExtrasEnabled. Both return with no error.

Oops, nevermind. I get the tools now if I right click on the viewer. I thought I’d tried that with both WebKitDeveloperExtras and WebKitDebugDeveloperExtrasEnabled, but maybe not. In any event, the tools now come up, and I’ve been able to track down the problem to at least a couple of the streams.

Apparently, over the past couple of weeks, these streaming sites have started rejecting http connections, and now require https. I should have considered that, but since the http URL worked fine when pasted into either Safari or Firefox, I assumed the problem must lie somewhere else. I guess Safari and Firefox both catch that error and automatically rewrite the URL to https and retry.

Anyway, thanks for suggesting the HTMLViewer web developer tools. I had no idea they existed. A new tool for my bag of tricks!