New issue
Advanced search Search tips

Issue 784447 link

Starred by 1 user
Status: Fixed
Owner:
grt@chromium.org
Closed: Nov 2017
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

[Mac] Chrome Mac receives Windows kTryChromeAgain command line flag

Project Member Reported by shrike@chromium.org, Nov 13 2017 
Chrome Version: 63.0.3239.40
OS: 10.12

This UMA histogram shows that Chrome Mac receives the kTryChromeAgain command line flag:

https://uma.googleplex.com/p/chrome/histograms/?endDate=20171111&dayCount=1&histograms=Launch.Modes&fixupData=true&showMax=true&filters=platform%2Ceq%2CM%2Cchannel%2Ceq%2C3%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

This flag corresponds to a Windows-only experiment - Chrome Mac should not receive it. This creates problems for accurate LM_ bucket counts (such as LM_MAC_DOCKED_DISK_LAUNCH vs. LM_MAC_UNDOCKED_DISK_LAUNCH).

ShouldRecordActiveUse() in active_use_util.cc returns kTryChromeAgain, and it's called from code in chrome_browser_main.cc that's wrapped in a #if !defined(OS_ANDROID) block - this appears to be the source of the kTryChromeAgain flag.

Comment 1 by grt@chromium.org, Nov 14 2017

Status: Started (was: Assigned)
ShouldRecordActiveUse returns true if --try-chrome-again is on the command line; it doesn't return kTryChromeAgain. If --try-chrome-again is on the command line, it's because someone/something outside of Chrome has put it there. Looks like there are some codepaths that handle it only when it has a value (e.g., --try-chrome-again=5), whereas others handle it if it's only present. I'll harmonize so that all codepaths are only active when there's a value.

Maybe someone put instructions on the web saying to use it for some reason? Have you checked crash/ to see if there's evidence of it present in crashes? I find it very odd for it to be used.

Comment 2 by grt@chromium.org, Nov 14 2017 

Oh, on second thought, the problem is that I inadvertently changed the meaning of bucket 9 in r475846. :-( If you filter on Milestone >= 62 you'll find that there are 0 in the LM_UER_EXPERIMENT bucket on Mac.

Apologies for the goof-up.

Comment 3 by grt@chromium.org, Nov 14 2017

Labels: -Pri-1 Pri-2
I'll still land the harmonization CL since it's technically the right thing.

As for analyzing the new LM_MAC_* values, those landed in M63, I believe, so you won't lose any data by filtering out data from M61 and lower.

Comment 4 by shrike@chromium.org, Nov 14 2017 

grt@ - Apologies for my analysis in the report. Maybe not enough coffee. I'm not sure how I misread it so badly.

Thank you for digging into the issue.

Comment 5 by grt@chromium.org, Nov 14 2017 

No worries!
Project Member

Comment 6 by bugdroid1@chromium.org, Nov 15 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/df00c4b0995a77054a8d786c394a6cf6f9f3df80

commit df00c4b0995a77054a8d786c394a6cf6f9f3df80
Author: Greg Thompson <grt@chromium.org>
Date: Wed Nov 15 19:52:34 2017

Ignore --try-chrome-again when no argument is given.

The browser startup codepaths that interpret it all require that it have
a value. This change applies the same policy to the other two places
that check for the switch on the command line.

BUG= 784447 

Change-Id: I62702cbd377ca95f15e56d3f64f3f13533f15abd
Reviewed-on: https://chromium-review.googlesource.com/768725
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516795}
[modify] https://crrev.com/df00c4b0995a77054a8d786c394a6cf6f9f3df80/chrome/browser/active_use_util.cc
[modify] https://crrev.com/df00c4b0995a77054a8d786c394a6cf6f9f3df80/chrome/browser/active_use_util_unittest.cc
[modify] https://crrev.com/df00c4b0995a77054a8d786c394a6cf6f9f3df80/chrome/browser/ui/startup/startup_browser_creator_impl.cc

Comment 7 by grt@chromium.org, Nov 16 2017

Status: Fixed (was: Started)
Marking as "fixed" in the sense that there's not much more to do here. Cheers.
►

Sign in to add a comment