I’ve read somewhere that I might have to send a Plist file to Apple but I am just at the development stage and I am not planning to release it. I also deactivated my firewall for a moment to test it, same result.
Anyone with the same issue?
Thanks,
Ps: Sorry to ask again. I see that many people had a similar issue in the past.
Also, a couple of weeks ago, if I wasn’t dreaming, I can almost swear that it was working when I followed a tutorial somewhere on the internet, which I can’t find anymore.
I followed your instructions, new project, only 1 htmlviewer called HTML, open event your line of code, running correctly with Xojo2019r3.1 and macOS Catalina. I’m sorry this doesn’t help you resolve your problem.
On Windows I experience the same, but not every time. (API 1) Cannot get a finger behing and I was wondering how I could detect this is happening in order to trigger reloading.
Just thinking out loud, but is CancelLoad being called? If not, you might be able to set a timer to check a variable and refresh the HTMLViewer if needed. Set the variable value in CancelLoad to show that the HTMLViewer instance is working and disable the Timer.
Thanks for the hint @Anthony_G_Cyphers.
I’ve added code to log if Cancelload is being called when the problem occurs. (which is only every now and than) . If not, then I will implement your timer suggestion, which I was thinking of already but I was not aware of the CancelLoad option to detect.
CancelLoad is called each time, even when I get a blank page. But, in cases it’s working well I measure a duration between CancelLoad and DocumentComplete events of < 3 sec. In cases the issue of a blank pages is displayed I have a time between these events of > 8 seconds. Probably I could use that to do some workaround programming.
Well, maybe not for production code, but you could at least use it to build a recursive example to attach to a feedback report. It’s just a strange issue. I’ve not seen it.
Maybe the documentcomplete should disable some timeout counting (or several ones) behind the scenes and it is not doing it, so, after complete, an internal timer, not disabled, unexpectedly fires the cancelload AFTER loaded?
I would love a report and a fast fix if confirmed instead.
Are you logging what the URL is when it gets called? I found it happens with some unexpected URL being reported (such as “about:blank”). So in one of my HTMLViewers I have this code in CancelLoad:
if (URL="about:blank" or URL.BeginsWith("file://")=True or URL.BeginsWith("c:\Users\")=True) then return false
ShowURL (URL)
return True
Then the desired page loads.
Added: here are some comments from that event handler:
// Called when the content of the mailbody is about to be replaced. If this is due to loading
// an html string into the control, then it seems URL will be “about:blank”.
//
// Under Win7 the page loaded from code goes via a temporary file. When an external link is
// clicked, the URL has the normal form, but also another event occurs with the “about:blank” URL.
Ah, you triggered my memory! There was an issue like this that I ran in to where it was trying to load a generated file and would get something like about:blank#blocked in the WebKit renderer. The HTMLViewer would show blank as a result. I think I solved it by ensuring that the temporary file I was attempting to use in my LoadPage call actually existed before calling LoadPage. I eventually added a loop to wait for the file to be created with a 10ms sleep before actually making the call.
Not sure if it’s the same issue, but that might help.
dim fTemp as FolderItem
#if XojoVersion > 2019.02 then
fTemp = FolderItem.TemporaryFile
if fTemp.Exists then fTemp.Remove()
if not fTemp.Exists then fTemp.CreateFolder()
#else
fTemp = GetTemporaryFolderItem
if fTemp.Exists then fTemp.Delete()
if not fTemp.Exists then fTemp.CreateAsFolder()
#endif
fTemp = fTemp.Child( "myHTMLViewerFile.html" )
if not fTemp.Exists then
dim t as TextOutputStream = TextOutputStream.Create( fTemp )
t.Close
t = nil
end if
while not fTemp.Exists
app.SleepCurrentThread( 10 )
wend
me.LoadPage( strPage, fTemp )
It equates to the “Not allowed to load local resource” error. It’s meant to protect the user’s filesystem by limiting certain kinds of access (think of a page designed to run in this box that reads password files and the like). I think there’s a CEF switch to turn this off, but better safe than sorry and all that.
I would fully agree, but for this desktop project I still use version 2019R1.1, the best release in my 7 years with Xojo. It seems issues in previous releases are not even looked at anymore.
I dislike this policy and sometimes get a bit demotivated to report all issues I hit during coding. Think along by Xojo friends on the forum is mostly more helpful.