SetFocus behavior in OSR

[sirheroics]

We're using CEF (C++) in an off-screen render configuration. The way our setup works is that the user is presented with a login page. They can then click an HTML button that takes them to an Apple specific login. This is one page we've had trouble displaying...Apple's "AppleID" OAUTH2 login page which has an input text field for a username. Once you type in a valid bit of text, their "next" button transition from disabled to enabled.

The issue is that while the keyboard and mouse events were properly appearing on the page, their javascript was never getting a FocusEvent (which is what they use to switch the next button from disabled to enabled). If we use the Dev-tools debugger and typed a single character, all of a sudden it would receive a FocusEvent and the page would work properly.

We're currently calling host->SetFocus(1) whenever the UI element containing the OSR texture gets focus in our app and calling host->SetFocus(0) whenever it loses focus. One of our engineers discovered that if we put a SetFocus(1) in our mouse handler, all of a sudden the page would work properly.

What I don't understand is why this is necessary. As I said, we're calling SetFocus(1) when the page becomes visible so I'm not sure where focus has gone that by the time they get to the Apple login, it needs to be called again. I've tried polling GetFocusedFrame and it's definitely set to the frame that it should be.

Does anyone have any suggestions how to debug this? Or am I misunderstanding a necessary piece of Focus?

[KatrinaS]

Basically what I do with mine (kind of like how your engineer discovered) is constantly grab focus, so when focus is lost a thread grabs it again, as soon as focus is lost it seems (in mUh Java at least) that something thinks there's nothing to do, it only reliably and snappily 'does stuff' when it has focus I'll have to look into this predicament at some point for sure, possibly a layout / container component problem but at the moe I'm like meh wotevs

[sirheroics]

Basically what I do with mine (kind of like how your engineer discovered) is constantly grab focus, so when focus is lost a thread grabs it again, as soon as focus is lost it seems (in mUh Java at least) that something thinks there's nothing to do, it only reliably and snappily 'does stuff' when it has focus I'll have to look into this predicament at some point for sure, possibly a layout / container component problem but at the moe I'm like meh wotevs

How do you detect when focus is lost?

[KatrinaS]

I guess I'm lucky because I can just add a (Java) FocusListener to the Component returned from CefBrowser.getUIComponent(), and this listener has a 'focusLost()' method If you look at the native portions of the Java release maybe you'll be able to decipher how's / what's going on

[sirheroics]

I just tried the CefClient test app with off-screen-rendering-enabled and it has the same issues on Apple's signin page. Oddly enough, if i go directly to the signin page it's fine however if i go somewhere else first that redirects to the signin page, Apple doesn't detect focus and their web elements won't enable.

[KatrinaS]

Looking at the source of Apple's iCloud login page (as an example), the text field does have some JavaScript (a load of bloat ) shenanigans attached to it that could be interfering in some way. Seems like that if the element doesn't have focus it becomes blurred and becomes inactive (and possibly disabled), I think (possibly) as an anti automation / bot measure