Better handle showing suggest apps dialog before previous one is hidden

Better handle showing suggest apps dialog before previous one is hidden

There is delay between suggest apps dialog restoring focus to file manager
window (which happens in BaseDialog.hide) and suggest dialog reporting
result and being marked not shown (which happens in onHide callback).
If another suggest apps dialog is started during that time, it should
fail silently instead of reporting error. Also, any widget container
state set by the new dialog should be reset.

BUG=477106
TEST=1. Open suggest apps dialog for a file.
2. Cancel the dialog by pressing 'Esc'.
3. Try to open an new dialog immediately by clicking 'Enter'
(the list entry for the initial file should have focus at this point)
4. Verify no error is shown.
5. Verify subsequent attempts to open the dialog succeed (after a second
or two)

Committed: https://crrev.com/e783c6b2f5924db874884e2f31232ffdeee47fb9
Cr-Commit-Position: refs/heads/master@{#326829}

[tbarzic, 2015-04-22 02:06:26]

tbarzic@chromium.org changed reviewers:
+ yoshiki@chromium.org

[yoshiki, 2015-04-24 08:09:50]

lgtm with nit

https://codereview.chromium.org/1082423003/diff/20001/ui/file_manager/file_ma...
File ui/file_manager/file_manager/foreground/js/ui/suggest_apps_dialog.js
(right):

https://codereview.chromium.org/1082423003/diff/20001/ui/file_manager/file_ma...
ui/file_manager/file_manager/foreground/js/ui/suggest_apps_dialog.js:170: //
Reset any widget state set in |this.widget_.ready()|.
nit: s/Reset/Resets/, and please mention that we intentionally ignore the result
from finalizeAndGetResult() in the comment.

[tbarzic, 2015-04-24 17:04:23]

https://codereview.chromium.org/1082423003/diff/20001/ui/file_manager/file_ma...
File ui/file_manager/file_manager/foreground/js/ui/suggest_apps_dialog.js
(right):

https://codereview.chromium.org/1082423003/diff/20001/ui/file_manager/file_ma...
ui/file_manager/file_manager/foreground/js/ui/suggest_apps_dialog.js:170: //
Reset any widget state set in |this.widget_.ready()|.
On 2015/04/24 08:09:50, yoshiki wrote:
> nit: s/Reset/Resets/, and please mention that we intentionally ignore the
result
> from finalizeAndGetResult() in the comment.
> 

I disagree with Resets, given the comment describes the intent of calling
finalizeAndGetResult, rather than describing the method itself.

(added comment about ignoring the result)

[tbarzic, 2015-04-24 17:04:55]

The CQ bit was checked by tbarzic@chromium.org

[tbarzic, 2015-04-24 17:04:55]

The patchset sent to the CQ was uploaded after l-g-t-m from yoshiki@chromium.org
Link to the patchset: https://codereview.chromium.org/1082423003/#ps40001
(title: "updated a comment, and rebase")

[commit-bot: I haz the power, 2015-04-24 17:05:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1082423003/40001

[yoshiki, 2015-04-24 17:29:45]

https://codereview.chromium.org/1082423003/diff/20001/ui/file_manager/file_ma...
File ui/file_manager/file_manager/foreground/js/ui/suggest_apps_dialog.js
(right):

https://codereview.chromium.org/1082423003/diff/20001/ui/file_manager/file_ma...
ui/file_manager/file_manager/foreground/js/ui/suggest_apps_dialog.js:170: //
Reset any widget state set in |this.widget_.ready()|.
On 2015/04/24 17:04:23, tbarzic wrote:
> On 2015/04/24 08:09:50, yoshiki wrote:
> > nit: s/Reset/Resets/, and please mention that we intentionally ignore the
> result
> > from finalizeAndGetResult() in the comment.
> > 
> 
> I disagree with Resets, given the comment describes the intent of calling
> finalizeAndGetResult, rather than describing the method itself.

I see, ok. sgtm.

[commit-bot: I haz the power, 2015-04-24 17:37:41]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-04-24 17:39:26]

Patchset 3 (id:??) landed as
https://crrev.com/e783c6b2f5924db874884e2f31232ffdeee47fb9
Cr-Commit-Position: refs/heads/master@{#326829}