ui/arc should not depend on //content/public/browser & //content/public/common |
|||||||
Issue descriptionIn 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
,
Sep 22 2017
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.
,
Sep 22 2017
+//components/arc owners for more detail.
,
Sep 22 2017
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.
,
Sep 25 2017
#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?
,
Sep 25 2017
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.
,
Sep 25 2017
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.
,
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.
,
Sep 25 2017
,
Sep 26
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 |
|||||||
Comment 1 by sky@chromium.org
, Sep 22 2017