Similar issue here bug cannot active any input method everywhere after upgrade to 51.0.2702.0 canary using mac 10.11

@c2: That is  Issue 601738 

Leaving this open for the original problem (maybe ekaramad's work in  Issue 578168  will work towards a fix for that).

 Issue 578168  could definitely have caused  Issue 601738 , but I doubt if it relates to the position of the IME popup.

There is also an old standing bug on IME input window position for hangouts ( crbug.com/503165 ). If this is not a regression, it could as well be due to the same issue given that PDF (MimeHandlerView) and hangouts (WebViewGuest) both rely on the same code in GuestViewBase.

I will take another look at this after a fix for  issue 601738 .

This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment #5:
I know this is a bit late. :)

Based on https://bugs.chromium.org/p/chromium/issues/detail?id=503165#c14 the issue for GuestView is 'more or less' fixed. Issues like this don't happen on <webview> any longer and similarly, they should not in MimeHandlerView. I have attached a video to clarify things (in the video the <input> on top of the PDF page is inserted using devtools and inspecting the PDF Extension).

My understanding is that the IME is broken due to the PepperPlugin code.

Deleted: pdf_ime_bug.mov 9.8 MB

pdf_ime_bug.mov 9.8 MB Download

This is still a bug in 59.0.3068.1

The same problem manifests on Windows (see attached and  http://crbug.com/59257#c28  ).   Issue 78681  is another related bug for Windows.

I think ChromeOS is the only place it works - see  Issue 132565 

Deleted: Screen Shot 2017-04-12 at 3.36.27 pm.png 115 KB

	Screen Shot 2017-04-12 at 3.36.27 pm.png 115 KB View Download

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'll take a shot...

This might have to do with SelectionBounds which if I am not mistaken are used on Windows and Mac and decide where the IME popup window appears. If this is the case then most probably pepper is not sending the bounds or sending incorrect ones. Or maybe the conversion to root RWHV coordinates is flawed.

In any case, I can definitely type with the IME and put Chinese characters into a PDF form. The only issue is the position of the IME box. I think this is because |text_input_caret_set_| is false to PepperPluginInstanceImpl::GetCaretBounds(). If I set some value there, I can move the IME box around. Will keep looking. Hopefully this is the right direction.

So if OutOfProcessInstance::FormTextFieldFocusChange() calls text_input_->UpdateCaretPostion(), then it starts mostly working. There are a few problems as is:

1) It does not work on the first click. Somewhere there may be an initialization problem. It is likely not in PPAPI or PDF code, as PepperPluginInstanceImpl::GetCaretBounds() returns reasonable values.
2) The IME box is a bit too far up and draws over the PDF form field. It needs to be moved down, but I'm not sure who should be doing that adjustment. I'm also not 100% sure what the caret rect is suppose to represent. Right now, I'm just testing with the mouse click position and a size of 0x0.
3) The PDF plugin allows navigating between form fields with the tab key, but FormTextFieldFocusChange() does not get called when that happens. So after pressing the tab key, the IME box position is out of sync. We need to solve that for bug 820278 anyway.

> 2) The IME box is a bit too far up and draws over the PDF form field. It needs to be moved down, but I'm not sure who should be doing that adjustment.

The plugin is expected to return the exact position (with no further adjustment necessary.)

> I'm also not 100% sure what the caret rect is suppose to represent.

The rectangle where typically the blinking caret is rendered (i.e., height ~= line-height & top-left=the top-left point where the next char will be inserted & width=0) should work.

1) So UpdateTextInputStateInternal is the source of TextInputState. Did you notice whether or not we do get the right TextInputType here right after pepper focus? Supposedly when Pepper changes focus RenderWidget::UpdateTextInputState() gets called which would then get the TextInputType from pepper.

2) How about the displacement in the position of the pepper plugin inside the extension? The pepper is the <object type="application/x-google-chrome-pdf"> which is inside the PDF extension. Supposedly no including the offset inside extension could contribute to the IME window showing a bit further top and to the left.
 
3) I wonder if this is relevant:
https://cs.chromium.org/chromium/src/content/renderer/render_widget.cc?rcl=02fba0f7637a70f2dbedd19eeeaa4c9b2bf08a2f&l=1222
so we should first see if we send updates. Furthermore, IIRC, on Aura at least, changing text input state from text to text for the same RenderWidgetHostView would not move the IME window. For OOPIF _a solution_ was to set it to none and then to text again by injecting a fake state:
https://chromium.googlesource.com/chromium/src/+/44c242985f1c9f81dc56e7d5122776250b1f1a66

So ideally, switching editable element/field should set the text input state to none before setting it back to text. If this happens and the IME window still does not move, then the bug is perhaps with the selection bounds/caret bounds.

> 2) How about the displacement in the position of the pepper plugin inside the extension?
This shouldn't be an issue--the coordinates reported from UpdateCaretBounds is treated as the relative in <object>.

> 3) I wonder if this is relevant:
I guess not. I think the function FormTextFieldFocusChange() mentioned in #13 is the one in PDF plugin, which is the thing that will trigger the RenderWidget to send updates--not the other way round.

Caret bounds change for every keystroke (= char insertion), i.e., even within the same text field focused.
Probably it needs to be updated in finer-grained timing than focus changes.