Add tests to qualify branded builds |
||
Issue descriptionRecently 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.
,
Jul 13 2016
Do we still need this bug given c#26 in Issue 624850 ?
,
Jul 13 2016
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 |
||
Comment 1 by mark@chromium.org
, Jul 13 2016