Issue 451627 in chromium: Multiple hidden xkb window and background page

[chro...@googlecode.com]

Status: Untriaged
Owner: shuc...@chromium.org
CC: xiy...@chromium.org, abod...@chromium.org
Labels: Type-Bug Pri-2 Cr-UI-Input-Text-IME OS-Chrome

New issue 451627 by xiy...@chromium.org: Multiple hidden xkb window and
background page
https://code.google.com/p/chromium/issues/detail?id=451627

Repro:
1. Login as a regular user
2. Open chrome:inpect and check "Extensions"

There are multiple instances of ChromeOS XKB (3 in my case).

Is this expected? Please clarify. Thanks

Attachments:
multiple_xkb_instance.png 48.3 KB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #1 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

This is known issue that XKB extension uses "incognito": "split".
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/chromeos/input_method/google_xkb_manifest.json&l=6

Therefore, there would be multiple extension instances for each profile
(e.g. login profile, etc.).
The reason we have to use "split" instead of "spanning" is because XKB
extension provides virtual keyboard page which is loaded into the virtual
keyboard window container. And according to
https://developer.chrome.com/extensions/manifest/incognito, the VK page
cannot be loaded at login screen if "incognito" is set to "spanning".

Spanning mode
The default for extensions and Chrome apps is "spanning", which means that
it will run in a single shared process. Any events or messages from an
incognito tab will be sent to the shared process, with an incognito flag
indicating where it came from. Because incognito tabs cannot use this
shared process, an extension using the "spanning" incognito mode will not
be able to load pages from its extension package into the main frame of an
incognito tab.

[chro...@googlecode.com]

Updates:
Cc: dpol...@chromium.org

Comment #2 on issue 451627 by xiy...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

+dpolukhin

Thanks for the clarification.

However, per ChromeProcessManagerDelegate::IsBackgroundPageAllowed, we
should not load extensions for the regular part of the login profile. So
for a regular user session, there should be only two XKB extensions: one
for the incognito login profile and one for user profile. I am not sure why
there are three. Could you double check?

[chro...@googlecode.com]

Updates:
Cc: kal...@chromium.org

Comment #3 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

With some log info, I confirm that the XKB extension is loaded as component
extension once at login screen and once after user logged in.
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/chromeos/input_method/component_extension_ime_manager_impl.cc&l=262

I think there might be some issues in the extension system with
incognito=split.

I observed in the 3 XKB extension instances, there is only one for
incognito (by opening inspect dev console).
And after closing the inspect dev console, the incognito XKB extension
instance is gone.
As for the 1 redundant XKB extension instance, it should be created after
user logged in.

+kalman@ who is familiar with extension system internal.

kalman@, do you have any ideas? Thanks

[chro...@googlecode.com]

Comment #5 on issue 451627 by kal...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

Requiring the use of incognito=split is a shame, and I wish it weren't
necessary (due to extra process requirement), but if it has a *bug* that's
a different issue entirely.

Looking at the manifest, it looks like the extension uses an event page.
Therefore, the login page version of the extension *should* shut down. 2
questions:
- does the login screen use a different profile, and is that profile ever
shut down?
- is there something the extension does which might keep its event page
alive, which may also include a bug in one of the private APIs it uses?

[chro...@googlecode.com]

Comment #8 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

Partially found the problem, the extension calls chrome.app.window.create()
unexpectedly.
After removing the unexpected calls of chrome.app.window.create(), the
background page can be killed correctly.

However:
1) there are still 3 instances temporarily (although 2 of them will be
killed when idle).
2) the remaining 1 instance is for login incognito profile.
3) open inspect dev console for the remaining instance and close it will
cause the instance be killed (this is weird).

[chro...@googlecode.com]

Comment #9 on issue 451627 by bugdro...@chromium.org: Multiple hidden xkb
window and background page
https://code.google.com/p/chromium/issues/detail?id=451627#c9

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/bef0893a2994abc9e68f8e98027a4d04590ddc7c

commit bef0893a2994abc9e68f8e98027a4d04590ddc7c
Author: shuchen <shu...@chromium.org>
Date: Mon Feb 02 02:49:32 2015

Don't awake suspended IME extension's background except for onActivate.

For suspended IME extension (e.g. XKB extension), don't awake it by IME
events except onActivate. The IME extension should be awake by other
events (e.g. runtime.onMessage) from its other pages. This is to save
memory for steady state Chrome OS on which the users don't want any
IME features.

BUG=451627
TEST=Verified on linux_chromeos.

Review URL: https://codereview.chromium.org/884713005

Cr-Commit-Position: refs/heads/master@{#314100}

[modify]
http://crrev.com/bef0893a2994abc9e68f8e98027a4d04590ddc7c/chrome/browser/extensions/api/input_ime/input_ime_api.cc

[chro...@googlecode.com]

Updates:
Labels: merge-merged-2293

Comment #10 on issue 451627 by bugdro...@chromium.org: Multiple hidden xkb
window and background page
https://code.google.com/p/chromium/issues/detail?id=451627#c10

[chro...@googlecode.com]

Comment #11 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

Issue 461514 has been merged into this issue.

[chro...@googlecode.com]

Comment #13 on issue 451627 by gary8sm...@gmail.com: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

I have this too. If I shut the XKB extensions down they come back again. If
they are for the virtual keyboard surely they should not appear until I
load the virtual Keyboard?



Attachments:
Screenshot 2015-04-23 at 23.37.43.png 102 KB

[chro...@googlecode.com]

Comment #14 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

This is a regression introduced in M43. The "Chrome OS XKB" extension by
default creates a NaCl module in its background which stops the extension
suspending.
This issue has been fixed in the latest M44 canary.

Re #12, for battery issue, with latest fixes, the "Chrome OS XKB" extension
won't listen to key events so it should behave better on battery life, as
well as key handling performance.

As for why there are 3 instances, that is because "Chrome OS XKB"
extension's manifest defines {"split": "incognito"}.
So the extension framework tries to create separated extension instances
once new profile coming up (including incognito profile such as login
profile).

The only reason to use {"split": "incognito"} is because at login screen
the virtual keyboard page is loaded in an "incognito" VK window container.

@kalman, do you have any idea how we can avoid using
{"split": "incognito"}? Thanks

[chro...@googlecode.com]

Updates:
Labels: M-44

Comment #15 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #16 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

Verified on 7015.0.0, there is no Chrome OS XKB instance after 15+ seconds
idle.

[chro...@googlecode.com]

Updates:
Status: Fixed

Comment #17 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #18 on issue 451627 by blaster...@googlemail.com: Multiple hidden

xkb window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

I currently have 7 entries on the Task Manager. Sometimes is rises to 10 or
more but never seems to drop below 5 identical entries.

Version 43.0.2357.46 beta (64-bit)
Platform 6946.31.0 (Official Build) beta-channel quawks
Firmware Google_Quawks.5216.204.6

Attachments:
Screenshot 2015-05-05 at 00.10.49 - Display 1.png 94.9 KB

[chro...@googlecode.com]

Updates:
Status: Verified

Comment #19 on issue 451627 by rookris...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #20 on issue 451627 by evlcbl8...@gmail.com: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

This was my Chromebook last night(will around 1 am)

Attachments:
Screenshot 2016-01-31 at 2.25.19 AM.png 120 KB

[chro...@googlecode.com]

Comment #21 on issue 451627 by evlcbl8...@gmail.com: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

This was what ended up on my Chromebook,At around 2-3am. Help fix this
problem.It's not getting better.

[chro...@googlecode.com]

Updates:
Status: Assigned
Labels: -Pri-2 -M-44 Pri-1 M-48

Comment #24 on issue 451627 by abod...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Cc: -kal...@chromium.org rdevlin...@chromium.org

Comment #25 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

-kalman@ +rdevlin.cronin@.

Devlin, the Chrome OS XKB IME extension relies on 2 things:
- Its manifest marks "incognito" as "split" so that it can work (e.g.
on-screen keyboard) at login screen.
- Its background marks "persistent" as false so that it can be suspended
when idle.

Was there some recent changes in the extension framework that can possibly
causes this issue?

[chro...@googlecode.com]

Comment #26 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

evlcbl8623@ & blaster219@, can you please tell more info about the
environment when this issue repros? e.g.
- Are you using multiple users switching?
- Does the issue repro after multiple logout/login or lock/unlcok?
- Do you often use incognito window?

[chro...@googlecode.com]

Comment #27 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

One more question,
- Are you using on-screen keyboard?

[chro...@googlecode.com]

Updates:
Cc: ni...@chromium.org

Comment #28 on issue 451627 by rdevlin...@chromium.org: Multiple hidden

xkb window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

+nick@ who owns task manager. Each entry in task manager doesn't
necessarily correspond to a separate process, so having multiple entries
for a single extension isn't necessarily wrong. That said, this does look
a bit weird. Nick, any ideas why we'd be showing so many entries for this
extension? (Totally random shot in the dark: it looks like
ExtensionInformation::GetAll() is checking each frame for the extension and
adding its WebContents, but there can be many frames in a single
WebContents - any chance we're double-counting?)

[chro...@googlecode.com]

Updates:
Owner: ni...@chromium.org
Cc: shuc...@chromium.org

Comment #29 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

Over to nick@ for confirming the root cause.

nick@, feel free to assign back to me if confirmed the root cause is not in
task manager or extension framework.

Currently I have a backup plan that avoid using "event page" for the Chrome
OS XKB extension.

[chro...@googlecode.com]

Updates:
Labels: Needs-Feedback

Comment #30 on issue 451627 by shuc...@chromium.org: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #31 on issue 451627 by evlcbl8...@gmail.com: Multiple hidden xkb

window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

I Was # 21 earlier on the list with 21 XKB extensions showing in task
manager on Jan. 31st around 2-3am

Version 48.0.2564.92 (64-bit)
Platform 7647.73.0 (Official Build) stable-channel gnawty
Firmware Google_Gnawty.5216.239.34

[chro...@googlecode.com]

Comment #34 on issue 451627 by rdevlin...@chromium.org: Multiple hidden

xkb window and background page
https://code.google.com/p/chromium/issues/detail?id=451627

The background page not being suspended explains one process entry, but I
think the question is why there are >10.