Harmonize modal "organic" first run dialog (Linux, Mac) |
||||||
Issue descriptionChrome Version : 63.0.3236.0 This dialog only surfaces for "organic" first runs for official builds on Linux and Mac, when there is no user data dir, and there is no managed prefs. So it's super rare to see it on any corp machine. I'm adding a --force-first-run-dialog flag to show it, since it creates a very strange startup flow and has poor test coverage. Attaching what it looks like on Mac currently. Since there's no Chrome UI visible yet, it could be argued that this dialog should be more native-looking rather than harmony-looking on Mac. Windows has a separate dialog that's shown as part of the installer (I think). That could just leave Linux.
,
Nov 15 2017
Issue 781757 has been merged into this issue.
,
Nov 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4d7d11d4addf64a6376b65f3227220da3e40241f commit 4d7d11d4addf64a6376b65f3227220da3e40241f Author: Trent Apted <tapted@chromium.org> Date: Fri Nov 17 07:42:51 2017 Add --force-first-run-dialog, regression tests for r511312. Chrome has a modal first-run dialog displayed during browser startup on Linux and Mac, before the main MessageLoop begins. It is supressed under many scenarios, and completely disabled in Chromium builds, making it very difficult to test (even manually). Before r511312 Chrome would upload a crash dump if a SIGTERM or similar was received while the dialog was showing on Mac. This CL adds --force-first-run-dialog which works in official and non- official builds for testing the dialog manually. Adds a regression test for r511312 to test signal handling while this dialog is showing. This also gives some bot coverage of the dialog code. Consolidates repeated and redundant logic leading up to the dialog invocation, allowing Linux/Mac to share the --force-first-run-dialog logic as well. The behaviour of the run loop used while the modal dialog runs also changed in r511673, which could cause Chrome to ignore SIGTERM while the dialog was showing. That's not ideal, so handle this as well. Bug: 777660 Change-Id: I523966003eda01d43f15d0217e075e11838da38a Reviewed-on: https://chromium-review.googlesource.com/734381 Reviewed-by: Greg Thompson <grt@chromium.org> Commit-Queue: Trent Apted <tapted@chromium.org> Cr-Commit-Position: refs/heads/master@{#517337} [modify] https://crrev.com/4d7d11d4addf64a6376b65f3227220da3e40241f/chrome/browser/first_run/first_run_dialog.h [modify] https://crrev.com/4d7d11d4addf64a6376b65f3227220da3e40241f/chrome/browser/first_run/first_run_internal_posix.cc [add] https://crrev.com/4d7d11d4addf64a6376b65f3227220da3e40241f/chrome/browser/first_run/first_run_internal_posix_browsertest.cc [modify] https://crrev.com/4d7d11d4addf64a6376b65f3227220da3e40241f/chrome/browser/ui/cocoa/first_run_dialog.mm [modify] https://crrev.com/4d7d11d4addf64a6376b65f3227220da3e40241f/chrome/browser/ui/views/first_run_dialog.cc [modify] https://crrev.com/4d7d11d4addf64a6376b65f3227220da3e40241f/chrome/browser/ui/views/first_run_dialog.h [modify] https://crrev.com/4d7d11d4addf64a6376b65f3227220da3e40241f/chrome/common/chrome_switches.cc [modify] https://crrev.com/4d7d11d4addf64a6376b65f3227220da3e40241f/chrome/common/chrome_switches.h [modify] https://crrev.com/4d7d11d4addf64a6376b65f3227220da3e40241f/chrome/test/BUILD.gn
,
Jan 23 2018
bettes@: do we want to do anything for these now or ever? They show before any Chrome UI is visible, so drawing as native-looking UI might be appropriate.
,
Mar 23 2018
MacViews triage: I'll own sorting this out for M68.
,
Apr 13 2018
,
Apr 17 2018
MacViews: I'm calling this WontFix, at least on the Mac side - we're going to ship an installer (and hence obsolete this bug) before we work on this. Untagging Mac and stripping MacViews labels.
,
May 25 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by tapted@chromium.org
, Oct 24 201712.8 KB
12.8 KB View Download