TMSFNCWebBrowser not allowing typing in components on Mac

FNC TMS FNC UI Pack
1

A am running into a really strange behaviour with an app deployed to MacOS. When the app is running on my mac, after you click on a TTMSFNCWebBrowser component (it doesn't matter if a webpage is loaded or any content is loaded in the web browser), then click on a TEdit component and attempt to type on the mac keyboard to enter characters into the TEdit component, all you get is beep sounds from the computer and no characters appears. But, if you simply click your mouse anywhere a second time in the app, you then can type in the TEdit.

It seems like the mac is somehow taking the cursor out of focus off the entire app as soon as you click the TTMSFNCWebBrowser component, so you have to click twice some where in the app in order to gain focus back into the app. I am just guessing.

any ideas on how to fix that issue?

to recreate this issue, simply create a new multi-device firemonkey app. Put a TTMSFNCWebBrowser component and TEdit component on the form. then deploy to the mac. Click the browser component and then click into the tedit component and try typing any characters into the tedit component and all you get is beep sounds and no characters appearing. like the mac is sounding an error has occured.

I am deploying the app from a windows 10 PC to a MacOS with version 11.7 Big Sur using the PAServer for Delphi 11. I also tested this on MacOS Monterey 12.6 and get the same issue.

2

I seem to have found a fix for this issue. In the FMX.TMSFNCWebBrowser.Mac.pas, I commented out the SetFocus line in the TTMSFNCMacWebBrowserEx.becomeFirstResponder function:

//if Assigned(FWebBrowser.FEdit) then
// FWebBrowser.FEdit.SetFocus;

after I commented out those 2 lines, that seemed to fix the issue. Appears to be some sort of focus issue.

3

Hi,

We implemented this because we couldn't get key input in the browser because of an underlying issue in the FMX framework. It consumes all keys. So when this does not happen, it basically makes input in the browser not possible. We'll investigate if we can workaround this.

4

Ok, I see. But after I commented those lines, the browser is not affected on macOS. It works as it should with input from the keyboard working fine inside the browser component. In addition, the issue I explained above was also fixed by commenting the setfocus code.

5

Thanks for the input, I'll investigate and see what the effects are.

6

We have investigated this issue here and applied a fix. Commenting the SetFocus lines was unfortunately not the correct solution (however, thank you for your investigation, which led to the correct fix). The fix actually needs to remove focus from the edit when the browser focus is cleared. (You can patch this manually for testing purposes, restore the original code and apply the following fix below)

function TTMSFNCMacWebBrowserEx.resignFirstResponder: Boolean;
{$HINTS OFF}
{$IF COMPILERVERSION >= 34}
var
  I: Integer;
  KeyMappingService: IFMXKeyMappingService;
{$IFEND}
{$HINTS ON}
begin
  Result := WKWebView(Super).resignFirstResponder;
  if not Assigned(FWebBrowser) then
    Exit;

  //ADDED
  if Assigned(FWebBrowser.FEdit) then
    FWebBrowser.FEdit.ResetFocus;
  //ADDED

The reason why the internal FEdit is created and receives focus is that when the browser receives focus, there are 2 carets, one for TEdit on the form, and one for the native browser control. By moving the focus to an internal offscreen edit, we make sure there is only one caret active at a time. Although the keyboard input is properly redirected, I assume the focused control remaining on TEdit although visually the focus is on TTMSFNCWebBrowser may cause unwanted side effects.

1 Like
7

That makes sense, thanks for the fix and explanation. I tested this fix and it works perfect! Thanks for the amazing support as usual :grinning:

1 Like