Hi, Nish -

No guarantees, but you might try adding a user event to the web browser control mapped to PB event code pbm_bnkillfocus. This appears to be the event that an OLE control contains that is named "LoseFocus".

Best regards, John

Well, I tested with a user event mapped to pbm_bnkillfocus without any luck. This might be caused by the web browser control not ever having received keyboard/input control (i.e., "focus"), as I did not test with a web page that contained an input field.

If your testing shows that this does not work, you might then try putting code in the WebBrowser control's Other event and in particular, take note when the Number property of the Message object contains the event ID of 8, which is the event ID for the Windows WM_KILLFOCUS event.

Here is a link to the Windows API explanation of the WM_KILLFOCUS event:

   https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-killfocus

Hi Nish;

  FYI ... there has already been a ticket opened for this missing feature. Engineering has confirmed that this is not supported by the current control (even mapping a user event). In PB 2022 R2, Engineering is planning to replace the current Chromium engine used (under the hood) that supports the built-in web control with Microsoft's WebView2. Hopefully, that will address this issue.

Regards ... Chris

Below is the code I placed in a web browser control's Other event:

Constant UnsignedInt WM_KILLFOCUS = 8  // The message ID for the WM_KILLFOCUS event.

// You can utilize a non-sorted ListBox control to keep a list of the
// event ID's handled by the Other event, if desired (a handy tip).
//lb_1.AddItem(String(Message.Number))

If Message.Number = WM_KILLFOCUS Then
   Post Function MessageBox("LoseFocus","The web browser has lost user input focus.")

   // Tell Windows the WM_KILLFOCUS message has been handled.
   Message.Processed = True
   Return 1
Else
   // Tell Windows this "other" message has NOT been handled.
   Message.Processed = False // This is the default
End If

Return 0

With this code in place, I do see a WM_KILLFOCUS event get fired... occasionally. However, it appears it occurs ONLY when an input field in the web page (like a search input field) is given input focus at some point, then you tab/backtab through the hot links in the page until finally, you tab out of the web browser control to another enabled control in the window.

I don't believe this is standard Windows control behavior, so this may be evidence that there are indeed "issues" with the Chromium-based browser, as Chris has alluded to.

Note the commented line near the top of the script. An unsorted ListBox control can be used to track/list all of the Windows WM_xxxxx event ID numbers handled by the Other event. This is a simple and easy way to see what events get sent to the catch-all "Other" event in PB.

There are lists of Windows Event ID numbers/names available on the web. Here's the one I use:

   https://wiki.winehq.org/List_Of_Windows_Messages

Once I have the WM_xxxxxx event name, I can look up more information about that event. Here is my go-to site for Windows API information:

   https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-api-list