New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 709360 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug


Participants' hotlists:
Fixing-touch


Sign in to add a comment

Switching the VK with the Globe icon changes the browser window back to the original size

Project Member Reported by satorux@google.com, Apr 7 2017

Issue description

Chrome Version       : 58.0.3029.51
OS Version: 9334.33.0

What steps will reproduce the problem?
1. Open gmail.com and click on Compose
2. Start typing something using the virtual keyboard
3. Switch to another language with the Globe icon

What is the expected result?

The browser window is resized at the step 2, so that the input area is visible to the user. The browser window remains the same at the step 3.

What happens instead of that?

The browser window is changed back to the original size at the step 3, thus the input area becomes invisible.

This is bad experience for users using 2+ input methods.

 

Comment 1 by oka@chromium.org, Apr 18 2017

Status: Started (was: Assigned)

Comment 2 by oka@chromium.org, Apr 19 2017

Omri, which behavior should be prefered on switching IME? Close once vs. showing gray background while switching. See the videos below.

Close once:  https://drive.google.com/a/google.com/file/d/0B7EYjkGAjRAhalQtWmo1S0c1akk/view?usp=sharing
Show gray background without closing: https://drive.google.com/open?id=0B7EYjkGAjRAhRXZXdGpCcFppM2M

Comment 3 by oka@chromium.org, Apr 19 2017

The current behavior is close once, and there is a comment that it's to match the behavior with android, but I heard from satorux@ that Android's behavior might change.
Re #3, here's what I meant:

I think 'close once' behavior on Android is triggered when switching between IMEs implemented as different APKs (ex. Gboard and Google Japanese Input).

If you switch languages inside of Gboard [1], 'close once' behavior isn't triggered, and the transition is very smooth. I think this is more desirable.

[1] You can add French in Gboard by: Settings -> System -> Languages & Input -> Languages -> Virtual Keyboard -> Gboard -> Languages). 


IIRC, the current behavior is to close the keyboard once if the target keyboard is from a different extension.
You can check it by adding other languages (e.g. Spanish).

Comment 6 by oka@chromium.org, Apr 19 2017

Yes. That is correct. No closing if the same extension.

2017年4月19日(水) 12:21 yhanada via monorail <
monorail+v2.3709940063@chromium.org>:
I'm guessing that 'close once' behavior is necessary on Android since the window manager cannot tell the dimension of the next IME?

I think we can avoid the behavior on Chrome OS if we know that the next IME will have the same dimension. The 2nd option (Show gray background without closing) in Comment 2 lgtm.

Comment 8 by oka@chromium.org, Apr 19 2017

As I tried with US and JP, the dimensions are the same. Not closing sgtm.
I thought Hangul (Korean) is a different extension from US and JP, but
actually it was the same extensios as JP.
Maybe Hangul specific IME has gone?
Cc: wuyingbing@chromium.org
+wuyingbing

Can we put all languages into one extension? Then transition between languages will be very quick.
Project Member

Comment 10 by bugdroid1@chromium.org, Apr 19 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1137b41f7fc845c2e7c6555c1d6dee6f75fa8236

commit 1137b41f7fc845c2e7c6555c1d6dee6f75fa8236
Author: oka <oka@chromium.org>
Date: Wed Apr 19 17:16:37 2017

Fix wrong viewport size on virtual keyboard IME change

On full width mode, the |requested_bounds| parameter passed to
SetChildBounds can have different offsets from the |new_bounds|
set to the keyboard container window, because only the height of the window
matters in full width mode. Therefore the value passed to
NotifyKeyboardBoundsChanging should be |new_bounds| instead of
|requested_bounds|. Otherwise wrong insets values are set to RWHVAs managing
overlapping aura windows and wrong viewports are calculated for those windows.

BUG= 709360 
TEST=manually tested the bug is fixed.

Review-Url: https://codereview.chromium.org/2830513002
Cr-Commit-Position: refs/heads/master@{#465648}

[modify] https://crrev.com/1137b41f7fc845c2e7c6555c1d6dee6f75fa8236/ui/keyboard/keyboard_layout_manager.cc

wuyingbing@ per comment #9, is it possible to put all languages into one extension?
It would be desirable to have the switch happen without having to close the IME (see videos of comment #2).
Cc: oka@chromium.org
Components: UI>Input>Text>IME
Owner: wuyingbing@chromium.org
This is a long standing known issue, and we used to have a plan to merge all input methods into one single extension.

Yingbing, can you please estimate the efforts? Thanks!

It's not big effort. 
The root cause is for CJK and other NON Latin languages, we always need to start IME decoder instance of NACL in the background.
It consumes the some memory. 
Previously. ChromeOS team want to save cost as mush as possible. They don't allow us to merge them in one extension.
So we have to split them into two extensions.
One is XKB extensions. For physical keyboard. IME decoder of NACL is default off. User enable auto correction will start the instance.
For virtual keyboard. It's default on. 
But ChromeOS will kill the instance when the background idle for some time.
 
The other is input tool extension. NACL IME decoder is default on. 

If ChromeOS team change the mind. I'd like to merge them together.


Yingbing, thank you for the comment.

> The root cause is for CJK and other NON Latin languages, we always need to start IME decoder instance of NACL in the background.

Can we make it smarter? If we merge all extensions into one, but if the user needs to type only English with a physical keyboard without auto correction, then, I suppose we don't have to start the NaCl module. Is it feasible?

> It consumes the some memory. 

As long as we can avoid starting the NaCl module, I'm guessing that memory usage won't increase too much. Is my guess reasonable?

Hi Satorux,
I can implement in the your way.
I consider the tech detail found that implement in this way, didn't consume more memory.
We can save memory before because of XKB extension didn't has background instance.
Then we add auto correction feature. That means whatever you turn on the feature or not.
It should always has background instance but without NACL instance.

I can do the update soon.
Project Member

Comment 17 by bugdroid1@chromium.org, May 23 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/df82c2f1f609cfe5cead26794eeb85320594c904

commit df82c2f1f609cfe5cead26794eeb85320594c904
Author: shuchen <shuchen@chromium.org>
Date: Tue May 23 03:11:19 2017

Merges google_input_tools extension into google_xkb extension. The google input tools extension relative clean up will be in other CL.

BUG= 709360 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

patch from issue 2894793002 at patchset 1 (http://crrev.com/2894793002#ps1)

Review-Url: https://codereview.chromium.org/2898873002
Cr-Commit-Position: refs/heads/master@{#473796}

[modify] https://crrev.com/df82c2f1f609cfe5cead26794eeb85320594c904/chrome/browser/chromeos/input_method/component_extension_ime_manager_impl.cc
[modify] https://crrev.com/df82c2f1f609cfe5cead26794eeb85320594c904/chrome/browser/resources/chromeos/input_method/google_xkb_manifest.json
[modify] https://crrev.com/df82c2f1f609cfe5cead26794eeb85320594c904/ui/base/ime/chromeos/extension_ime_util.h

Status: Fixed (was: Started)
Labels: VerifyIn-61

Comment 21 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment