Google Chrome and LostFocus oddity

We have encountered some very strange behavior on WebEdditon and Google chrome. We can reproduce the problem at will, but We cant seem to narrow down WHY it is happening.

It is potentially an issue that is big enough to bring down any Xojo web app. It explains some weird Xojo Cloud issues that @Greg O’Lone has indicated is probably "out of memory

We are looking for suggestions to isolate the problem /(bug?)

• We have subclassed WebTextField.
• Let call the class New_WebTextField
• In New_WebTextField.LostFocus we are doing some minor stuff like trimming white space from the user input, checking to see if it s validly formatted email address etc.
• We put a New_WebTextField on a page. Call it Webpage1.New_WebTextField1

  • No code calls Call it Webpage1.New_WebTextField.text in any way

Run the app
Safari: No issue
Edge: No Issue
Chrome: User #1 No Issue
Chrome User #2 : !! The LostFocus event fires even if we don’t touch the New_WebTextField.
and when we move to the next page New_WebTextField.LostFocus fire in an infinite loop until the app is dragged

Switch to another user other than User #2 and no issue.

Dead Ends:
Tried User 2 on multiple macs and multiple IP addresses --> no glory
User #2 had Chrome Sync Anywhere turned on. We turned it off. --> no glory
Turn off all chome extension -->no glory

Can anyone think of any other “Switch” to flip and test? We are at a dead end.

You could try opening the chrome developer tools and inspecting the textfield and then ensure the Javascript events are hooked to the object to call back to the Xojo server app.

Could you show this code? Does it call SetFocus if the validation fails?

It sounds like LostFocus accesses the Text property.


I maybe find the one and posted it to Feedback #50949.
Please find it in the feedback and let me know if I am missing something.

Yoshitaka MURAOKA

We have been seeing problems with Google Chrome as well when running XOJO web apps. We found that there is a weird interaction with the Google Chrome Password Manager. We disabled the password manager and the problem seems to go away. We also ran into a similar problem with Microsoft Edge with a password manager enabled.

We also found that by setting the AutoComplete property for a WebTextField to “off” the password manager no longer cause a problem although we did still need to make sure that a password was not saved for that website.

Not sure if this is relevant to your problem or not but it’s something we discovered recently.

If you haven’t already Jeff, please document all of that into a feedback case. We fixed a few of the interactions with password managers about a year ago, but it seems that they’ve come up with some new and wonderful ways to insert text without firing Text Changed events in the browsers. :frowning:

Reported in Feedback Case: 51073