HTMLviewer Blank page, once more....

General
#5

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.

#6

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.

#7

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.

#8

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.

1 Like
#9

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.

1 Like
#10

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.

#11

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.

#12

There’s a clear bug here.

#13

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.

#14

This is what I ended up with:

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 )
HTMLViewer.LoadPage(string,Nil) not show images
#15

Actually, if it’s what I’m thinking it is, it’s a security feature in the updated CEF version.

#16

How does this amount to a “security feature”?

#17

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.

1 Like
#18

Do you know how to apply that switch?

#19

It must be done in the HTMLViewer plugin by Xojo.

#20

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.

#21

I could be completely off-base here. @William_Yu could probably elaborate and fix any mistakes I’ve made.

1 Like
#22

Yes but this is silly, isn’t it? If I want to read the password files I just do it in Xojo code. What would be the point of implementing that in an HTML page, then loading that into an HTMLViewer. If I can do it in the latter I can do it in the former.

#23

I can’t speak with any authority as to how Xojo evaluates what CEF switches to use in their HTMLViewer plugin.

#24