browser_options should not contain a copy of the finder_options |
||||||
Issue descriptionA copy is currently kept here: https://cs.chromium.org/chromium/src/third_party/catapult/telemetry/telemetry/internal/browser/browser_options.py?rcl=30e5a9f19de9cff42ee5ff8b5d9a4be5546e3588&l=318 The need for that copy appears to be: https://cs.chromium.org/chromium/src/tools/perf/core/perf_benchmark.py?rcl=2e8c61cc50bcb9b3f50ff48cbce259003c10ba8a&l=40 where we - take the finder_options out of the browser_options - use the finder_options to build, again, a new possible_browser - use the possible_browser to read target_os from it! surely we could save the target_os somewhere else, maybe even the browser_options themselves, rather than current very roundabout way?
,
Jan 12 2018
This is only needed for https://cs.chromium.org/chromium/src/tools/perf/core/perf_benchmark.py?rcl=2e8c61cc50bcb9b3f50ff48cbce259003c10ba8a&l=40 I think the easiest fix is to replace CustomizeBrowserOptions(browser_options) with CustomizeOptions(finder_options)
,
Jan 12 2018
I think that's a step back in the wrong direction. _GetVariationsBrowserArgs should not need to neither know the finder options, nor create a possible browser. It just wants to know the target_os, which we should be able to figure out earlier.
,
Jan 12 2018
That's possible too. Though another reason I want to replace CustomizeBrowserOptions(browser_options) with CustomizeOptions(finder_options) is to make these benchmarks hooks to be less browser specific
,
Jan 12 2018
I can see how that makes sense. Which (non-browser) options might a benchmark want to customize? Now, even if we make that API change, I would still argue that _GetVariationsBrowserArgs should have no need to create a possible_browser just to figure out the target_os.
,
Jan 12 2018
Examples of which (non-browser) options might a benchmark want to customize: - A general startup benchmark may want to expose a commandline option for user to decide which cache level do user wants on the platform. - A ChromeCustomTab benchmark may want to expose a commandline option for user to select their own embedder app APK I do agree with you _GetVariationsBrowserArgs should have no need to create a possible_browser just to figure out the target_os. So doing these two will make the code better, and doing any of them should be enough to get rid of the copy of the finder_options. I do think fixing _GetVariationsBrowserArgs may be easier; so I file a separate bug about replacing CustomizeBrowserOptions(browser_options) (issue 801528)
,
Jan 12 2018
Hmhh, actually I think _GetVariationsBrowserArgs may not need possible_browser to get target_os, but it would need finder_options (where we store --device flag) to get target_os. So issue 801528 is actually blocking this.
,
Jan 12 2018
yup sgtm fixing those two bugs either way which makes things easier.
,
Jan 14
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 14
,
Jan 15
,
Jan 16
(6 days ago)
,
Jan 16
(6 days ago)
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by perezju@chromium.org
, Jan 12 2018