danni...@, could you attach a Chrome app you mentioned in the original post?
You seem to have forgot to attach.

I'm guessing this is an general issue of <webview> tag for Chrome apps, right?
https://developer.chrome.com/apps/tags/webview

In that case, it would be reproducible with this:
https://chrome.google.com/webstore/detail/browser-sample/edggnmnajhcbhlnpjnogkjpghaikidaa
(I confirmed basic IME is working on Windows, Mac, and Chrome OS)

I'm not sure what step 4. and 5. are trying.  What's the expected binding
for Ctrl+K and Ctrl+J?

Changwan, if the problem becomes clear, could you handle this?

Oops, here it is. Did you also not get the video?

Ctrl+K is bound to focus an input field that is not a part of the webview, Ctrl+J focuses the webview.

Deleted: webview_ime.zip 2.1 KB

webview_ime.zip 2.1 KB Download

Deleted: ime-bug.ogv 1.7 MB

	ime-bug.ogv 1.7 MB View Download

ekaramad@ - Is this possibly related to your work? Do you perhaps already have a fix for this?

I don't believe it is related to any of my changes. I also could not reproduce this problem on Mac. 

My guess is that the issue is with browser plugin <webview> and a race condition such as the one in  issue 546645 . For mouse focus perhaps this is less evident since the <input>  (I am guessing) goes to embedder process first and (maybe we lose focus and a TextInputState of NONE) and then to guest where we get the mouse focus correctly.

But when it comes to <webvidew>.focus() my guess is: the sources of TextInputState update are 1) webview.focus() will call BrowserPluginGuest::OnFocus which then restores the last text input state for guest (if we were in an input field when webview lost focus then it should be ui::TEXT_INPUT_TYPE_TEXT), and 2) the embedder/app itself loses focus and if it already had a focused <input> it will send a ui::TEXT_INPUT_STATE_NONE. Since these updates go to RenderWidgetHostViewAura::TextInputStateChanged, there is an inherent race, i.e., we might overwrite the guest TextInputState by that of the embedder.

danny.v20@gmail.com: Do you know if this issue existed before? If my understanding of the problem above is correct, this must have been a bug for a while. Also, can you please look in chrome://flags for "Cross process frames for guests" and see whether it is Default/Disabled or Enabled. With Enabled this bug should not happen but that being said, this feature is still experimental.

In comment #4 I meant to say "I could not reproduce this on Linux". I did not try it on Mac.

I don't know if this problem existed before. I tried enabling "Cross process frames for guest" and it still happens. The Ctrl+K (embedder input field) shortcut doesn't seem to work anymore with that enabled so I clicked the input field and then pressed Ctrl+J for webview.focus().

I also tried it on the latest chrome version from here: https://github.com/scheib/chromium-latest-linux

As ekaramad@ pointed out in #4, this is likely a duplicate of  issue 546645 , which I found and filed back in 2015.

Since ekaramad@ is assigned to that bug, I'll reassign this to him.

kochi@, I don't have bandwidth for non-Android issue for now anyways. Sorry about that.

If this happens with enabling cross process frames for guests, then the root cause might be different from  issue 546645  given that based on OOPIFs, the state for each RWHV is tracked separately. I will take another look then.

RenderWidgetHostViewGuest::TextInputStateChanged() seems to set the information correctly but it gets overwritten afterwards by RenderWidgetHostImpl::OnTextInputStateChanged().

I put this in, as an experiment, and the issue disappeared:

void RenderWidgetHostImpl::OnTextInputStateChanged(
    const TextInputState& params) {

  if (view_) {
    ui::TextInputClient *text_input_client = view_->GetTextInputClient();
    if(params.show_ime_if_needed && text_input_client)
      const_cast<TextInputState&>(params).type =
        text_input_client->GetTextInputType();
  }
}

I don't know if that helps.

Oops, removed one line from the code above, meant to post this:

void RenderWidgetHostImpl::OnTextInputStateChanged(
    const TextInputState& params) {

  if (view_) {
    ui::TextInputClient *text_input_client = view_->GetTextInputClient();
    if(params.show_ime_if_needed && text_input_client)
      const_cast<TextInputState&>(params).type =
        text_input_client->GetTextInputType();

    view_->TextInputStateChanged(params);
  }
}

danni.v20: Thanks for digging into this. The code in comment #10 stops the state to change back to NONE when focusing the <webview> which seemingly fixes this bug but it will most probably break IME on other fronts (it is mutating the state from the renderer).

Now as for the non-OOPIF <webview> (the one using RWHVGuest), there seems to be a difference in behavior when we tab into the email input in the app from that of Ctrl+J.

When we tab in, BrowserPluginGuest::SetFocus call will restore the last text input state (which is type=4 for email). But unfortunately embedder sends another update with type = 0 which overwrites this. But fortunately :) the renderer for the guest process will update its TextInputState which overwrites it back to type 4.

However when we Ctrl + J into the <webview>, the last update from the renderer does not arrive. I am trying to figure out why that happens. Maybe be it has something to do with user gesture.

I have a patch in progress here:
https://codereview.chromium.org/2755723002/

which fixes the issue for BrowserPlugin. The case for CrossProcessFramesForGuests will be tracked in a master issue 631798.

changwan@: adding you as an IME reviewer to the CL. Thanks!

I tried the patch and indeed it solves the problem. Thanks for taking the time to work on this. :)

Triage: This appears to have stalled out. Is this still an issue?

Archiving old bugs that have only received trivial updates for some time.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!

It's been working fine for a while now. Thanks guys!