I’m working on a program that needs to be able to show a preview of any specified webpage. Between inconsistent focus behavior, relatively limited functionality (e.g. no “view source”), and what seems to be sluggish rendering, I’m at my wits’ end with this control.
(By the way, what I really want for this specific program is nothing more than a preview of any webpage. I’m not developing a web browser and would like to discourage users from treating it like one. Alas and not surprisingly, DrawInto doesn’t work on the HTMLViewer.)
The latest in my frustration is that I’ve encountered instances where it simply hard crashes. To be sure, I created a sandbox app with nothing but the HTMLViewer control and nothing more than “LoadURL” in the Open event. In this case, just scrolling up (above the top of the page) causes the program to crash, as seen in this picture:
This behavior happens consistently with the Yahoo homepage, but not on other pages, which makes the issue a little harder to diagnose.
Can anyone replicate this, or know of a workaround, or a way to catch HTMLViewer exceptions so they don’t hard crash?
I can confirm that Yahoo crashes on Mac with HTMLviewer when scrolling extensively.
On Mac the “Native” and “Webkit” renders are one in the same. What we don’t know if how its implemented underneath. I know that recently the “Webkit” renderer on Windows was updated to CEF3. I believe that requires the Xojo framework to maintain a separate thread for manipulating the renderer based on explanations of why CEF3 was not implemented more recently.
IF the Mac native renderer works in a similar fashion then its possible they are not catching a specific error that is crashing the framework. All very hypothetical here but unfortunately we have limited capability to diagnose the issue(s).
Seems to only occur in 32 bit variant - possibly memory related. The crash dump indicated it capped out at 1 GB and crashed although thats not indicated in Activity Monitor. Possible the overuse of scrolling prevents the thread from cleaning up properly? In 64-bit mode it essentially just keeps climbing in memory usage.
Unfortunately, as you can see in the short video clip I posted, that scrolling can hardly be described as extensive.
I’m afraid you might be right…
Thanks for checking this, Phillip. I should probably switch the project over to 64 bit anyways…
This is probably a dumb question but I’ll ask anyways: I’m assuming that the renderer is coming directly from the OS, not from Xojo. If the OS is up to date, so is the renderer. Correct?
For me “extensive” was keep scrolling up and down for about 10-15 seconds. The memory just climbed until it crashed. I don’t think the memory reported in Activity Monitor is accurate compared to what the raw error displayed via macOS once the app crashed.
My understanding is on Cocoa they use the built in WebView component built into macOS. It is used in all kinds of applications outside of Xojo so I am going to assume something with how they implement it is failing and it is not crashing gracefully.
I don’t know that 64-bit actually solves the problem. I think it just masks the issue due to higher memory constraints.
In this case, I think I’ve decided to put a Canvas on top of the HTMLViewer that grabs the mouse events and keyboard input, and then manually handling the tab key to prevent the HTMLViewer from ever getting focus.
As I mentioned above, I only want the viewer to provide a preview not to allow normal interaction. I theorize that it’s much less likely that the HTMLViewer will crash if I effectively disable scrolling. Canvas.AcceptFocus and javascript to the rescue!
While I’m on the subject… Is anyone aware of any other crash-inducing HTMLViewer actions that I should try to block?
My program makes heavy use of the HTMLViewer and I have yet to experience a crash from it…
Xojo 2017r1, 32-bit and 64-bit debug builds…
Didn’t see an increase in memory usage (in Activity Monitor) but there was a bump in the CPU usage…
I use two finger scrolling on a MacBook Pro, incase that makes a difference…
Create a new desktop application, placed a HTMLViewer with the following code in the Open event: me.LoadURL "https://ca.yahoo.com/?p=us"
Xojo 2017r1, 32-bit and 64-bit debug builds
Didn’t see an increase in memory usage, nor any crashes
Again, two finger scrolling
All tests were completed on a MacBook Pro (Late 2008) running Mac OS 10.10.5 (which could be the difference due to the different system libraries)…
On macOS you can use the following extends method to grab a screen capture of the visible HTMLViewer… Basically it takes a screen capture of the window and then hacks out the HTMLViewer part… This was originally posted to the original REALbasic forum by eudosia
[code]Public Sub DrawInto(Extends viewer As HTMLViewer, graphics As Graphics) #if TargetCocoa
// draw the window in into a picture cropped at the top-left of the viewer
DIM windowPicture As NEW Picture(viewer.TrueWindow.Width, viewer.TrueWindow.Height)
viewer.TrueWindow.DrawInto windowPicture.Graphics, 0, 0
// draw the windowPicture into the passed graphics object, but crop to the width and height of the viewer
graphics.DrawPicture windowPicture, 0, 0, viewer.Width, viewer.Height, viewer.Left, viewer.Top, viewer.Width, viewer.Height
Thanks for your response! Yes, I’m using two finger scrolling, too. My memory DOES increase when scrolling on the page, but not significantly.
This could be. I’m on a MacBook Air running 10.12.5. I assume that the webkit libraries would be newer and less likely to crash.
Interestingly, that sortof works. Except, it immediately hard crashed when I called the extension from the canvas Paint event. I moved it to a separate method, setting a picture variable. This worked for a moment, and then hard crashed.
I just crashed it on 10.12.5 as well… Stock Xojo 2017r1.1 installation, 32-bit debug build, using Yahoo as the URL, two finger scrolling, just scrolled a few times and poof away it went…
Thanks for checking it out, and for the test program.
I think I’m going to stick to my aforementioned method of using a canvas to take focus away from the HTMLviewer. So far, it seems to be the most consistently stable option. The extension might be useful in some cases, but it’s essentially the same thing as using Window.DrawInto.
Anyone found a work around for this? I’ve just hit what I think is the same (or a related) problem.
I have an app containing nothing but an HTMLViewer and the only code is in the open event. It simply opens the url to stream from an ip camera on my local network.
The video streams fine for about a minute and then there is a hard crash.
