regression of text-box-focus-after-alert bug?

[michaeladamkatz]

This is regarding viewtopic.php?f=6&t=16558

which was documented to have been fixed in 3626: https://bitbucket.org/chromiumembedded/ ... cef-builds

However, I just downloaded and built 3729 (Windows 32 bit) and I'm seeing the same behavior where after an alert I can't focus on text inputs (until I switch to another application and then back to my CEF application).

(I updated from 3578 to 3729 only to get this bug fix. )

Can you repro this in 3729?

[ndesktop]

This was merged in 02-12-2019. Maybe 3729 you downloaded was built before that?

[michaeladamkatz]

Is that possible? I downloaded from here: http://opensource.spotify.com/cefbuilds/index.html

The date it says is 06/04/2019, four months later, right?

[michaeladamkatz]

https://bitbucket.org/chromiumembedded/ ... cef-builds says the fix was made on the master branch on 2019-02-11, and the repository shows that commit (f85816f) made to master on that date. The repository shows 3729 being branched from master on 2019-03-14. So it would seem this fix should be in 3729?

See attached image. I don't quite understand way bitbucket shows the all branches view. It shows this fix (59d1f01) happening on branch 3683, but doesn't show f85816f happening on master. But when you view the history for just master you do see f85816f on that date.

[michaeladamkatz]

I've downloaded the source code for 3729 (https://bitbucket.org/chromiumembedded/ ... 29.tar.bz2) and it does indeed have the changes in https://bitbucket.org/chromiumembedded/ ... ts/f85816f.

So the mystery is why I'm still getting the behavior where after an alert box I cannot focus a text field. Can you please try a simple page with an alert() call and a text input and see if you get the same behavior in 3729 and/or the current master branch?

[michaeladamkatz]

Update: I've tried the out-of-the-box cefclient in 3729 and it does NOT have this text focus problem. I am trying to narrow down the differences between that and my modified cefclient. I thought at first it might be that I'm building for Multi-threaded DLL (/MD) instead of Multi-threaded static (/MT), but that didn't make a difference. I thought it might be that I wasn't linking with cef_sandbox.lib, but that wasn't it. Working on it...

[ndesktop]

3729 indeed have the change. I don't think is a /MT vs /MD thing, otherwise you would not be able to link statically.
Most likely is a quirky SetFocus - usually is - or a side effect of other message. Try to use MSAA tools to see the focus flow.

[michaeladamkatz]

Thanks for hanging in there with me.

You've helped me narrow the problem to a location that should have been more obvious to me, which is that I register a JSDialogHandler. See code below. I do this pretty much only because I don't like that the default alert dialog box shows the URL of the application in the title bar.

Do you see a problem with my code? Is it possible that the case of a custom dialog handler like this wasn't covered in the fix to this problem in the commits referenced above?

(I have confirmed that when I do not use this handler, or when I return false from OnJSDialog, the focus problem goes away. In fact I can even show my own MessageBox and then return false from OnJSDialog, which shows the default dialog box after my MessageBox, and then doesn't have the focus problem.)

Code: Select all


class NoaaJSDialogHandler : public CefJSDialogHandler
{
public:
  explicit NoaaJSDialogHandler();
  virtual bool OnJSDialog(CefRefPtr<CefBrowser> browser,
                          const CefString& origin_url,
                          JSDialogType dialog_type,
                          const CefString& message_text,
                          const CefString& default_prompt_text,
                          CefRefPtr<CefJSDialogCallback> callback,
                          bool& suppress_message) OVERRIDE;
  virtual bool OnBeforeUnloadDialog(CefRefPtr<CefBrowser> browser,
                                    const CefString& message_text,
                                    bool is_reload,
                                    CefRefPtr<CefJSDialogCallback> callback) OVERRIDE;
   
  void OnDialogClosed(CefRefPtr<CefBrowser> browser) OVERRIDE;
 
private:
  IMPLEMENT_REFCOUNTING(NoaaJSDialogHandler);
  DISALLOW_COPY_AND_ASSIGN(NoaaJSDialogHandler);
};

  this->_noaaJSdialogHandler = new NoaaJSDialogHandler();

  CefRefPtr<CefJSDialogHandler> GetJSDialogHandler() OVERRIDE {
    return this->_noaaJSdialogHandler;
  }

bool NoaaJSDialogHandler::OnJSDialog(CefRefPtr<CefBrowser> browser,
                                        const CefString& origin_url,
                                        JSDialogType dialog_type,
                                        const CefString& message_text,
                                        const CefString& default_prompt_text,
                                        CefRefPtr<CefJSDialogCallback> callback,
                                        bool& suppress_message)
{
   switch ( dialog_type )
   {
      case JSDIALOGTYPE_ALERT:
      {
         MessageBox( browser->GetHost()->GetWindowHandle(), message_text.c_str(), L"My App", MB_OK );
         callback->Continue( true, "" );
         
         return true;
      }
   }
   
   return false;
}

bool NoaaJSDialogHandler::OnBeforeUnloadDialog(CefRefPtr<CefBrowser> browser,
                                                  const CefString& message_text,
                                                  bool is_reload,
                                                  CefRefPtr<CefJSDialogCallback> callback)
{
   callback->Continue( true, "" );
   
   return true;
}

void NoaaJSDialogHandler::OnDialogClosed(CefRefPtr<CefBrowser> browser)
{
}



[ndesktop]

I'm not sure I understand the whole thing, but I suppose the flow is
- focus on DOM element x
- JS fires MessageBox
- MessageBox closes
- focus is not on DOM element x

If this is the case, I'd try this:
- call GetFocusedFrame to get the current focused frame before MessageBox ==> CefFrame focusedFrame (and optionally CefBrowser and its browser ID)
- maybe SendCaptureLostEvent to the browser of focusedFrame (GetBrowser().SendCaptureLostEvent())
- let MB do its thing
- when MB is closed, using the browser ID from the first step: locate the browser with that ID, if still valid call browser->SetFocus

If that won't do, try this route:
- CefDOMDocument visitor and GetFocusedNode => focused node
- handle focus as above
- implement OnGotFocus (I hope it will be called after MB closes and you call SetFocus on browser)
- inside OnGotFocus call a javascript (I don't know how to programmatically set focus on a DOM element, there is no SetFocusedNode) to set the focus on the saved element

Remember this is what I'm thinking, I never wrote a clear focus restorer per element. Maybe browser is smart enough to restore focus correctly after browser.SetFocus.

[michaeladamkatz]

Thanks for your help, but my guess is that there's something else that has to be done inside of libcef.dll to make the original bug fix work in the case of a derived CefJSDialogHandler.

Just to clarify (not sure if it was clear), the problem here is not simply trying to automatically refocus the browser element that was focused before the message box. The problem is that once a that message box shows and goes away, the user cannot click on *any* text input in the program to focus it. You have to alt-tab to another application and then back to the cefclient application to make it so you can click and focus text boxes again.

Here is the code I tried for your first idea, which made no difference.

Code: Select all

case JSDIALOGTYPE_ALERT:
      {
         CefRefPtr<CefFrame> frame = browser->GetFocusedFrame();
         browser->GetHost()->SendCaptureLostEvent();
         MessageBox( browser->GetHost()->GetWindowHandle(), message_text.c_str(), L"Tier2 Submit", MB_OK );
         browser->GetHost()->SetFocus( true );
         callback->Continue( true, "" );
         
         return true;
      }


I didn't try your second idea because it seemed more specifically about just trying to refocus the element that had focus.

For now I'm just going to avoid use of alert() and use message boxes made of DOM elements.