When Chrome shows a dialog and then almost immediately hides it again, the user is confused, not having been able to read the dialog's contents. The dialog should always stay visible at least for the time needed to scan its contents, once it is shown.

For example, the progress dialog during exporting passwords shows the words "Exporting passwords" and "cancel". Given that the user can read about 200 words per minute, the dialog should stay up for at least one second (unless dismissed directly by the user) to avoid a bad user experience. org.chromium.chrome.browser.preferences.password.DialogManager ensures within ExportFlow.java that that particular progress dialog indeed always stays up for at least one second unless dismissed directly by the user.

But Chromium also has other places which use DialogFragment to show dialogs. These should also be able to benefit from such delayed hiding. Therefore this bug tracks the following steps:

(1) Inspecting all places using DialogFragment other than ExportFlow (currently including ConfirmSyncDataStateMachineDelegate and AccountManagementFragment) and checking whether those dialogs can get closed by Chrome without user interaction.

Assuming that such places other than ExportFlow are found:

(2) Migrating org.chromium.chrome.browser.preferences.password.DialogManager to org.chromium.chrome.browser.widget.DelayedHidingDialogManager.

(3) Switching all the places identified in (1) to use the new DelayedHidingDialogManager. The hiding delay should be configured for each case separately, to reflect the amount of text present on such dialog (delay = (200 / 60) / #of_words)


Notes:
* There are other ways in which Chrome displays dialogs than DialogFragment. Those might suffer from the same issue, but fixing those requires more work and is out of scope of this tracking report.
* There are related refactorings planned or needed: migrating off of deprecated patterns like DialogFragment itself or android.app.ProgressDialog; extending ModalDialogManager outside just chrome/, or a unification of all Dialog-using patterns in Chromium). These might interfere with this task, but this task should be easier and quicker to do than those refactorings.
* Once (3) is finished, one might consider if a presubmit check to avoid using plain DialogFragment might be needed. So far it seems like the likelihood of introducing regressions accidentally is too low to justify delaying all CL uploads by running such check.
* Ultimately, the goal is to have all dialogs handled in a similar way and the hide-delay logic applied to all cases, not just those which happen to use DialogFragment. One step towards that would be integrating the logic into what is now ModalDialogManager. However, for that the clash between DialogFragment needs to be solved, as well as the differences like the ModalDialogManager being per-activity vs. DialogManager per-DialogFragment, or the (unused) ability of stacking DialogFragments but not Dialogs under ModalDialogManager. All of that is beyond what this report tracks.

(This was initially discussed on a Google-only e-mail thread: go/vvwgu.)