aight, sooo
chrome/browser/ui/webui/options
chrome/browser/resources/options
are no longer used on Win, Linux, and Mac.
because there are a few UIs built on top of chrome://settings-frame/* URLs on ChromeOS, it's very very hard to detangle which of the options resources or C++ handlers to remove. they have very hard-to-track encapsulation. .js files reference other .js files implicitly or are explicitly loaded by <script> or <include>. the .js files also use $('id-name-in-html') like candy, which requires .html templates to exist. any chrome.send() may correspond to a C++ handler, which may also have other #include dependencies. additionally, chrome.<extension>Private requires a host-based whitelisting of a private extension API.
tl;dr - It'll be hard to remove /options/ from src/ completely while those ChromeOS-only UIs exist.
The long term plan is to eliminate all of the options dependencies from Chrome OS also. We are in the process of triaging that effort. I am gardening this week but hope to spend some time next week prioritizing so that we can weed out the larger chunks of code.
I hope to at least triage the effort next week.
dbeam@ or michaelpg@ was going to come up with at least a partial list of the known dependencies.
I plan to look through the dependencies myself and at least triage them next week. At that point we should have a better idea of the effort involved.
Un-owned bugs have a habit of falling through the cracks (started state actually makes it worse since we usually don't search for that pattern)
Who should own this?
^ if anybody was wondering how bidi checker is related, it loaded the old settings URL (which both stevenjb@ and I found when grepping for the URL constant, presumably)
Comment 1 by dbeam@chromium.org
, Jun 6 2017