I was hoping to be able to pass some data out of the web page being displayed by using the statusChanged event, unfortunately this seems to be completely broken on the Pi? My testing shows that it fires only with empty values and only when you first mouse over the control and lots of times with more empty values when you select any text in the displayed page or mouse over any selected text. Never when you specifically tell it to window.status=a test message for the status event or something like that.
It APPEARS to me, though I am not a linux expert by any means, that the needed webkit libraries are now part of the default Raspian distribution. If I do a " apt-mark showauto | grep webkit from the command line I see that it is installing the following:
libwebkit2gtk-4.0-37
libwebkitgtk-3.0-0
The second of which looks to fulfill all of Xojos requirements for the HTML viewer does it not?
<https://xojo.com/issue/56308>
The Web Page Title event does seem to work, so i am going to attempt to use that to send the data though, but that is going to do more filtering and limiting than the status. Really what I want is something akin to the xojoScript context class that can call into xojo code from javascript, or at least pass me some JSON data or something. As a matter of fact I am going to go and make a feature request for that right now.
I had to implement a websocket server in my app to avoid using these two events. But if there isn’t a standard way for an HTMLViewer to send arbitrary data to the surrounding Xojo app via an event, then it’s a big hole in things.
That ‘feature’ has was disabled a couple of years ago as a security risk.
You will need to the title changed event, but be aware that is limited to 4K data.
This post has more info.
[quote=444449:@John A Knight, Jr]That ‘feature’ has was disabled a couple of years ago as a security risk.
You will need to the title changed event, but be aware that is limited to 4K data.
This post has more info.[/quote]
So… let me see if I understand this 
I can no longer use a page status because of a security risk… but I can use the title with exactly the same information in it up to around 4k or so and that is somehow not a security risk? I am not a security expert but locking the back door and leaving the front door open doesnt actually seem like a fix for any problem I can imagine as far as Im concerned It still works fine on MacOS so they dont think its a security risk. Or there is something else between the event and its information on MacOS that makes it not a security risk. Perhaps they should explore that as an option rather than just turning something that is useful to us off.
But then the only reason its useful it because were over taking it to get info in and out of the HTMLViewer. Xojo needs to update their documentation to say that this event is useless on Linux at the very least. That would have saved me an entire day of screwing around. And then to solve the problem needs to offer something akin to the context class they have for the xojoScript object so that I can call into and get data out of an HTML viewer! And no, the current request to just get the results of an execute javascript command is not enough. I need to be able to receive events out of the html viewer, not just ask it about things. Otherwise its completely limited to displaying HTML that would be better shown inside a web browser entirely.
[quote=444449:@John A Knight, Jr]That ‘feature’ has was disabled a couple of years ago as a security risk.
You will need to the title changed event, but be aware that is limited to 4K data.[/quote]
And before implementing a websocket server, I tried getting the data out of an HTMLViewer in 4k chunks using the TitleChanged event, labelling each chunk so that the Xojo app could reassemble them into the original arbitrarily sized blob. This worked fine under macOS (by fine I mean it worked quickly) but under at least WIndows each chunk was taking more than 100msec or so, so very slow for larger blocks. At which point I gave up on this approach.
My project got whacked on Windows when 2017r1 came out. Windows and Linux (and Pi) all lost use of the page status at that time. I’m surprised Mac still works. The rationale was that too many phishing/web spoofing sites would change the status to imitate the original site. Protecting the page status would help exposing fake sites.
AH, OK that makes sense. Under normal usage the page status displays the full URL of the page you visited, and if people were changing that to make their phishing site look more real then I get why that would be something they might want to do.
Of course, even that doesnt make a whole lot of sense since the URL field at the top of every page should also display the page address and path that you visited shouldnt it? Mine does… But maybe I set a preference at some point a long time ago and forgot about it.