//components/omnibox depends on //extensions, possibly violating the layering rule
Reported by
most...@opera.com,
May 26 2017
|
||||||
Issue description//components/omnibox depends on //extensions which IIUC is specific to the chrome layer. This appears to violate the layering rule, ie that components are only supposed to depend upon lower layers. Reference: https://chromium.googlesource.com/chromium/src/+/master/components/README
,
May 26 2017
,
Jun 5 2017
+ brettw for //url/OWNERS
The only thing we depend on is extensions::kExtensionScheme ("chrome-extension"). Seems like it would be appropriate to move this to a common location: url/url_constants.h. Any objections?
,
Jun 5 2017
Actually +brettw this time.
,
Jun 5 2017
I know in the past we've had many discussions around the "chrome-extension" scheme (and similar constants). A lot of folks think that the scheme itself is a layering violation, and shouldn't be extended to components that truly don't rely on extensions (e.g., blink allows currying in these constants through e.g. AddSecureScheme). At a high level, I think I would probably take that pedantic point of view, mostly because if a component truly *only* relies on the scheme, it should be possible to pass it in through a generic concept. Omnibox, on the other hand, actually has a number of extension-y concepts, like processing extension keywords. These could all probably be factored out, but I think that (refactoring) should be the answer, rather than hoisting up extension-y constants to a higher-level shared library. A middle-ground solution would be having something like //extensions/constants that things like omnibox could depend on without depending on the rest of the extensions module, which I think could be okay (since it prevents further inclusion and still [imo accurately] depicts the partial dependency on extensions).
,
Jun 28 2017
,
Sep 28 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by jochen@chromium.org
, May 26 2017