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

Issue 697587 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Task

Blocking:
issue 670496



Sign in to add a comment

exo shouldn't use ash::kShellWindowId_*Container

Project Member Reported by penghuang@chromium.org, Mar 1 2017

Issue description

exo shouldn't use ash::kShellWindowId_*Container
 
Blocking: -670496 672961

Comment 2 by varkha@chromium.org, Sep 20 2017

Blocking: -672961 670496
Cc: reve...@chromium.org sky@chromium.org osh...@chromium.org sadrul@chromium.org varkha@chromium.org penghuang@chromium.org
May not be a blocker for mus_ash if ash and exo are in the same process. We can discuss this more if there are still benefits to better isolation.

Comment 3 by osh...@chromium.org, Sep 20 2017

I think that's necessary in short/mid term and even may be better because exo also handles notification stuff, unless it has to be separated.

Comment 4 by sadrul@chromium.org, Sep 20 2017

exo can use the ash container ids even in mus+ash. See examples in chrome (e.g. [1]).

[1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/bluetooth/bluetooth_pairing_dialog.cc?l=72

Comment 5 by sadrul@chromium.org, Sep 20 2017

(i.e. even if ash and exo are running in different processes)
Components: -Internals>MUS Internals>Services>WindowService
Status: WontFix (was: Untriaged)
Ash and exo are staying in the same process, so this is fine.

Sign in to add a comment