On Mon, Oct 7, 2013 at 2:42 PM, Ojan Vafai <o...@chromium.org> wrote:
> If I were to try to find all the places where we enable different > settings, where would I look? Does cs.chromium.org capture all our ports? > Many of them come from chrome flags, which in turn may be set from outside the chromium codebase. Eg. ChromeOS hard-codes several flags here: https://chromium.googlesource.com/chromiumos/platform/login_manager/+/master/session_manager_setup.sh . Maybe a UseCounter for settings would help <grin>? On Mon, Oct 7, 2013 at 11:39 AM, Rick Byers <rby...@chromium.org> wrote: > >> I agree this is important. Even for those of us using blink for the >> Chrome browser it can be a real source of pain and confusion, not to >> mention it harder to get good test coverage (eg. do we really have linux >> layout tests which use the same set of Settings as ChromeOS supplies by >> default?). >> >> I propose a couple principles we should try to follow (and document in >> Settings.in): >> >> 1. Settings should default to the common/safe value (if you don't >> know what a setting does, you generally should not need to override it). >> 2. Settings should have a description in Settings.in about why >> they're needed >> 3. When settings are added to help stage the roll-out of a new >> feature, reviewers should ensure a bug is filed to track removal of the >> setting once it's no longer experimental. >> >> I've filed the following bugs to the appropriate owners for some settings >> that I've got context for. Unfortunately I don't think any of them can be >> removed just yet, but many shouldn't be more than a couple milestones out. >> >> - 304518 <http://crbug.com/304518>: remove compositorTouchHitTesting >> - 304869 <http://crbug.com/304869>: >> remove pinchVirtualViewportEnabled and useSolidColorScrollbars >> - 304873 <http://crbug.com/304873>: remove touchEditingEnabled >> - 304894 <http://crbug.com/304894>: remove touchDragDropEnabled >> - 304895 <http://crbug.com/304895>: remove touchAdjustmentEnabled >> - 304895 <http://crbug.com/>: remove >> acceleratedCompositingForOverflowScrollEnabled >> - 304900 <http://crbug.com/304900>: >> remove acceleratedCompositingForScrollableFramesEnabled >> and compositedScrollingForFramesEnabled >> >> Rick >> >> >> >> On Mon, Oct 7, 2013 at 11:53 AM, Adam Barth <aba...@chromium.org> wrote: >> >>> On Mon, Oct 7, 2013 at 4:20 AM, Kenneth Rohde Christiansen < >>> kenneth.christian...@gmail.com> wrote: >>> >>>> Hi there, >>>> >>>> As someone using Chromium/Blink for slightly other purposes than the >>>> Chrome browser, I find it very hard to figure out the proper settings >>>> configuration. >>>> >>>> Some settings are opt-in, opt-out, and some are for specific platforms >>>> only. >>>> >>> >>> Yes, our settings are still a bit of a mess. We've made some progress >>> cleaning up the RuntimeEnabledFeatures [1], but the Settings object [2] is >>> still a bit of a swamp. >>> >>> It would be very useful to know the strategy behind the setting. Like >>>> does the setting exist because the feature isn't properly >>>> tested/implemented yet to be enabled on all platforms? Is it supposed >>>> to be the way we do things in the future, or does it just exist as a >>>> result of legacy? >>>> >>> >>> For RuntimeEnabledFeatures, we have a |status| field that indicates the >>> maturity of the setting. We should probably add a comment for each feature >>> that doesn't have a |status| field indicating what it's status is. For >>> example, if a feature exists for a given platform or embedder, we should >>> say that in a comment. >>> >>> This is impossible to know from the settings name. At least, it would >>>> be really useful to easily see whether enabling or disabling a setting >>>> would give you the "old tested safe behavior" or the "new experimental >>>> behavior" etc. >>>> >>> >>> For the Settings object, many of the settings are only ever set to one >>> value. We did a sweep a while ago to remove settings that weren't even >>> exposed in the API, but we should do another sweep to clean up settings >>> that are exposed but aren't ever changed. >>> >>> However, even after we do that, we're still going to have a bunch of >>> settings. I'm happy to review CLs that add comments to Settings.in that >>> explain why we have each setting. It's probably a bunch of work to >>> research that information, but it will likely be useful information to have. >>> >>> I am open to suggestions and I can write some CL's if people can help >>>> me with this. >>>> >>> >>> I would certainly welcome CLs that remove unused settings or that add >>> documentation as to why settings exist. I'm also happy to answer questions >>> on IRC, but we're probably going go need to do some archeology to figure >>> some of them out. >>> >>> Adam >>> >>> >>> [1] >>> http://src.chromium.org/viewvc/blink/trunk/Source/core/page/RuntimeEnabledFeatures.in >>> [2] >>> http://src.chromium.org/viewvc/blink/trunk/Source/core/page/Settings.in >>> >>> >> >
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
