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

Issue 767990 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Sep 26
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 768439
issue 672961



Sign in to add a comment

ui/arc should not depend on //content/public/browser & //content/public/common

Project Member Reported by penghuang@chromium.org, Sep 22 2017

Issue description

In mus+ash, exo should be able to run without browser process,
To run exo without browser process, //ui/arc should not depend on  //content/public/browser & //content/public/common.

The chain of dependencies:
  //ui/arc:arc ->
  //components/arc:arc_base ->
  //components/keyed_service/content:content ->
  //content/public/browser:browser

 

Comment 1 by sky@chromium.org, Sep 22 2017

Any idea what arc_base is using from content?
The BrowserContext is used by ArcBrowserContextKeyedServiceFactoryBase in arc_base. It is used to create ARC++ related services, and to maintain their life cycle with BrowerContext I think.


 
Cc: elijahtaylor@chromium.org lhchavez@chromium.org hidehiko@chromium.org yusukes@chromium.org
+//components/arc owners for more detail. 
Owner: hidehiko@chromium.org
Status: Assigned (was: Untriaged)
ui/arc/notification/arc_notification_manager.cc actually includes and uses components/arc/arc_browser_context_keyed_service_factory_base.h. Forwarding this to hidehiko@ who introduced the service.


#2, that's true.
ARC's services are tied to Profile, and their lifetime is managed via BrowserContextKeyedService (destroyed with Profile).
ArcNotificationManager is the case.

By introducing delegate, we can move it to e.g. components/arc/notification, assuming we allow dependency from components/arc to ui/arc (yusukes@, lhchavez@, could you just double check?).

Yoshiki, do you have any thoughts about moving?

Cc: jamescook@chromium.org
There may have another issue. I found the //ui/arc needs the ArcBridgeService (which is in the browser process) to do the IPC with ARC++. and the //ui/arc also need access exo to get notification surface, and access message_center to control systray. But for mus+ash, the browser, ash (message_center) and exo are not running in the same process I think, we can not access them directly.

Comment 7 by sky@chromium.org, Sep 25 2017

Cc: est...@chromium.org
Peng, please file individual bugs for each area that needs to be updated and make them blocking this.
As to ui/arc using ArcBridgeService. I believe ArcBridgeService is mostly a collection of mojom interfaces. Could some of these go to ash instead?
Notifications are moving to ash.
Parts of message center are moving to ash, but not necessarily all. estade@ knows more about message center.

Comment 8 by est...@chromium.org, Sep 25 2017

The plan is for the message center to live in ash on ChromeOS and the browser process on those desktop platforms which don't have native notification integration. The browser process will ask ash to display notifications. All other notifications besides arc only need to pass images and text (and respond to inputs); I don't know how arc notifications and exo surfaces will be passed across process lines.
Blocking: 768439
Status: Fixed (was: Assigned)
There is no more ui/arc. It was the home of arc_notification_manager and friends and they are moved to ash now.

Sign in to add a comment