New issue
Advanced search Search tips

Issue 801513 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

browser_options should not contain a copy of the finder_options

Project Member Reported by perezju@chromium.org, Jan 12 2018

Issue description

A 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?
 
Components: Speed>Telemetry
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)
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.
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
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.
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)
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.
yup sgtm fixing those two bugs either way which makes things easier.
Project Member

Comment 9 by sheriffbot@chromium.org, Jan 14

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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
Cc: -nedngu...@google.com
Cc: crouleau@chromium.org
Status: Available (was: Untriaged)

Comment 12 by benhenry@google.com, Jan 16 (6 days ago)

Components: Test>Telemetry

Comment 13 by benhenry@google.com, Jan 16 (6 days ago)

Components: -Speed>Telemetry

Sign in to add a comment