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

Issue 726696 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Task

Blocking:
issue 726700



Sign in to add a comment

//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
 

Comment 1 by jochen@chromium.org, May 26 2017

Cc: jam@chromium.org rdevlin....@chromium.org

Comment 2 by most...@opera.com, May 26 2017

Blocking: 726700
Owner: jdonnelly@chromium.org
Status: Assigned (was: Untriaged)
+ 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?
Cc: brettw@chromium.org
Actually +brettw this time.
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).
Labels: Hotlist-CodeHealth Hotlist-Refactoring

Comment 7 by most...@vewd.com, Sep 28 2017

Cc: -hu...@opera.com most...@vewd.com hu...@vewd.com

Sign in to add a comment