Or we need some further checking in the framework for when a control is no longer on the page. As my projects have gotten more and more complicated and Im sending more and more updates to live items on the page I can regularly get that javascript error “send to us” dialog when in reality nothing has gone wrong. Its simply that Ive changed a property of something on the page within a moment of the user having switched to another page. That message from xojo goes into the queue and instead of just realizing that its control is no longer there and that nothing bad has happened it crashes the session with that error message.
The framework could probably completely ignore errors where the call to Xojo.get just returns nil. Thats because a control got a message after the browser side framework deleted it or the page it was on. I cant immediately think of an example where this would be useful for debugging, but I understand if developers are cautious about just ignoring errors 
Perhaps a beta vs implementation mode where you can turn off such strict error checking for situations that are not errors?
I am actually considering performing some sacrilege and replacing the pages global error handler with one to send me the data but to leave the user alone via the execute javascript command. Thats so totally against the rules that Im a bit amazed at my own audacity to even think such a thing But these are NOT real errors, the user just clicked away and I had controls updating before the server side got the message and the close or hidden events.
I have to trap hidden events and not closed events since hidden happens right away but closed takes some considerable time after the page is left to happen. Perhaps that is a bug too, Im not sure yet.
This seems like something that shouldn’t happen in “normal” usage. The user clicks a button, which asks the server what to do, which tells the client to dismiss a view. The client and server should be in sync.
Could this be a side effect of custom controls or JavaScript that is putting the two out of sync?
It’s an issue in the web framework where we don’t always check to see if a DOM element exists before calling a setter. I’ve been working to wrap these in try-catch when I find them, but there’s still a few places that do this.
I have found that web list boxes have this issue and raise errors that seem to have no real reason.
Depending on the heaviness of the webpage, i wouldn’t close the webpage if a user action would cause a page change, at least not before i have been assured that all commands send to the page were arrived and implemented. What i do mostly is just load and display the second page without closing the first one. In that case all changes that are still traveling to the browser can reach their destination without a problem and won’t cause a javascript error.
Just the same with listboxes, hide the first one while displaying the second. Of course this will not solve all cases, but maybe it helps someone.
Is there yet a solution? Will the new framework solve this issue?
One of the basic precautions to take is not to put any code calling other controls in controls Open event, as well as in webPage Open event. Most errors have to do with the DOM not being ready when one calls a control.
An easy way to go around that is to place the code a single webTimer on the page with period like 100ms. Since a webTimer is part of the controls, it won’t fire until the DOM is fully formed.
Another way is to put code in Shown, but you got to use a webPage boolean property such as deja, so you can do something like :
[code]If not deja then
deja = True
// Do stuff
end if[/code]
That way the code executes only at the webPage opening, not every time it is shown.
Of course using your own JavaScript may also cause JS errors and show the big black dialog of shame, so you may want to put a Try Catch in there :
https://www.w3schools.com/js/js_errors.asp
yes, I always wrap my own javascript into try catch blocks when I send it. Thats easy enough but if it errors then you wont get the effect you were going for so while it stops the popup it wont stop there potentially being some random stuff for the user to see sometimes.
try{ your; javascript; here;}catch(re){}
I suppose you could try to trigger a server event to report the error if it happens and then know you had to resend whatever the command was…
That’s the catch… (could not resist). There is no way to suppress errors on a whole page, and even if there was, we would risk facing silent failures.
I trust Greg to continue is wrapping into Try Catch.
Of course he won’t know where to fix it without bug reports in Feedback…
Here’s what I do for my desktop app:
- In the HTML page that’s loaded you can have:
window.onerror = function (errmess, url, linenum) // Make JavaScript errors more visible
{
window.status = "Error:JavaScript error at line " + linenum + " - " + errmess;
}
Then back on the Xojo side I have a handler for the status event. You can parse the string returned as the new status and then decide what to do with it.
I should have added that I don’t bother with try/catch for the most part. Only where it would be normal that a fail may occur, such as being told that a file is an SQLite database when it may not be. Then I go through a sequence of attempts to perform operations on the supposed database and see if they succeed, each of which is in a try/catch.
With javascript, if there’s a problem then having the line-number reported can pin it down and then ordinary debugging techniques can find the problem.
I wonder if that would work in a web app… I’ll give it a crack sometime.
My other problem, which I have mentioned elsewhere, is " the big black dialog of shame" is not responsive to mobile screen sizes. I wonder if by using Tim’s approach I can do away with Xojo’s dialog all together and offer the customer something that is viewable on mobiles and matches my colour scheme.