New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 627657 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug



Sign in to add a comment

Add tests to qualify branded builds

Project Member Reported by shrike@chromium.org, Jul 12 2016

Issue description

Recently Chrome Mac started crashing on first run ( Issue 624850 ), but we currently have no first run tests to catch such an event. We need such tests ASAP.

From mark@:

At the very least, the tests should involve an installation of Chrome on a virgin system that’s never seen Chrome before. If it won’t run in this configuration, it’s obviously very bad.

You should test to make sure that Chrome launches and that the various options in the first run dialog work and do the right thing. People (including developers and testers) don’t normally see the first run dialog, so breakage may not be noticed, but it’s especially important to make sure that it all works because this is the first impression that we make on new users.

If you’re testing using VMs, it should be easy to reset to a Chrome-free state. Otherwise, you’ll need to get creative. Something like:

rm -rf '/Applications/Google Chrome.app'
rm -rf ~/Library/Application Support/Google/Chrome
rm -rf ~/Library/Caches/Google/Chrome
rm -rf ~/Library/Preferences/com.google.Chrome.plist
~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/ksinstall --nuke

That last one will depend on how and where Keystone is installed. If it’s system Keystone, you’ll need to run it out of the root /Library instead of the per-user ~/Library. If it’s system Keystone but there are user tickets, sudo ksinstall --nuke may not remove your user’s tickets, in which case a separate rm -rf ~/Library/Google/GoogleSoftwareUpdate may be necessary. Don’t run this command without a successful ksinstall --nuke first, though.

 

Comment 1 by mark@chromium.org, Jul 13 2016

Cc: manoranj...@chromium.org
The bit I wrote that shrike copied was something I provided in response to a request by Mano, so +him.

Comment 2 by shrike@chromium.org, Jul 13 2016

Do we still need this bug given c#26 in  Issue 624850 ?

Comment 3 by mark@chromium.org, Jul 13 2016

Status: Fixed (was: Untriaged)
The relevant bits there were the changes Mano made at go/chrome-te/home/backend/mac-chrome-breakpad-and-keystone-testing. I think that those changes address and resolve this bug.

Sign in to add a comment