Tested on Windows 10 - Xojo 2020r2
I checked out an app using LostFocus on a WebTextField and discovered that LostFocus fires up just fine in FireFox.
So Chrome and Brave are verified by me as NOT working with LostFocus unless the Tab key is used to navigate between fields. Chrome and Brave suck, FireFox rocks.
Off-this-topic, additionally, ANYone on here using GoDaddy may discover that Chrome does not work with their control panels but FireFox works with it perfectly.
This is a known problem. <https://xojo.com/issue/61985>
I have a fix for this in TP Webkit.
https://strawberrysw.com/tp-webkit/
I was just looking at that - I tested my app in three different browsers and this issue is not apparent in FireFox but I will absolutely consider getting it bc I actually like Chrome a lot better than any other browser.
I love your DRM solution - would it be possible for you to develop a shopping cart solution integrating either FastSpring or Stripe or PayPal?
This kind of thing is essential for SAAS and I am now forced to do manual transactions for customers but would love to buy something like your TPLM (DRM).
Strange and unexpected behavior. And if it should to be expected this way, than put a note in the documentation.
@Geoff_Perlman gives a sample with which he cannot reproduce the problem, while @Amy_Barnes and I can with Chrome on Win10.
It’s a bug. One browser ok, another not, etc. Tim even said he had to create a workaround to the bug. The fix should be just baked into the framework. @Amy_Barnes, please, don’t mark it as solved, or the case could potentially be ignored as if it was an user error corrected by the user.
It’s a bug we have on our schedule to fix for 2021r1. Of course that’s not a guarantee but we will be looking into it.
Why? It’s not a solution, it’s not even a promise.
I am eager for an in framework fix, but to mark it as a solution would be wrong. You can’t build an app on not-even-promises.
agreed, Geoffs answer is the solution when they deliver, not before that.
@Rick_Araujo is correct; Geoff’s response is indeed the solution to the actual problem, it just is not YET implemented.
not really
It is not solved until it is really solved …
It’ll be the solution when implemented. I’d remove the [SOLVED] word from the title, because it’s not really solved, just the solution was presented. It’s schedule for 2021r1. In case of not accomplishing it, it’ll be another disappointment, but it’s the ONLY solution possible. Anything else are just workarounds because the bug is still baked into the framework causing problems everywhere until noticed.
It is solved though, I offer a interim workaround. You seem to really want to dismiss my efforts here…
No way Tim. I appreciate very much your efforts with those workarounds that surpass very much this only case stated in here, and would say to anyone needing such workarounds for now a “go for it”. But in no way I would say “well, Tim have a workaround for it, let’s give up and not ask for fixing it”.
Amy has picked the solution that she feels best addresses her concerns. Let’s move on.
The OP asked about the bug, now that xojo has aswered, well, that solves the question.
A workaround is not the same as a fix/solution for the bug
By the way, Brave also uses Chromium, you will have the same behavior most of the wime than Chrome.