Just to update, able to repro this on 60.0.3112.10 on Linux Ubuntu 14.04 as well.

The scenario isnot applicable to Windows or Mac as no 2 save dialogs are seen clicking continuously the save icon.

This is a Regression issue seen from M-59

Manual Bisect Info:
====================
Good Build:59.0.3047.0
Bad Build: 59.0.3048.0

Users experienced this crash on the following builds:

Linux Beta 59.0.3071.71 -  0.56 CPM, 11 reports, 2 clients (signature tc_calloc)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/34d74089ce961adad864ed974ce27f7bdf270f17..0ff8b19608421be5fa5b53e90c097e4992723b90

thomasanderson@: Could you please take a look at this.

Note: Marking this as Stable blocker for M-59 as this results in browser crash and is regressed in M-59.

Unfortunately, this is a bug in GTK, and I'm not sure there's much we can do. (able to repro on Ubuntu 14.04 which has Gtk 3.10, but unable to repro on Ubuntu 16.04 which has Gtk 3.18)

I can repro this just by having 2 Chrome windows open, each with a save dialog, and then closing one of the dialogs.

Maybe we can limit to just 1 open dialog at at time?  Or maybe there's a Chrome save dialog that we can fallback on instead for affected versions of GTK?

Users experienced this crash on the following builds:

Linux Dev 60.0.3112.10 -  32.25 CPM, 2 reports, 1 clients (signature tc_calloc)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

I'd be tempted to punt on this if it wasn't for Googlers still being on 14.04 for at least a while longer.

The chrome save dialog isn't shipped outside of chromeos, and it's a pretty large extension. I'd advise not going down that route. Forcing other dialogs to Cancel seems fine if it's just done on the offending versions of gtk.

> Forcing other dialogs to Cancel seems fine if it's just done on the offending versions of gtk.

Should we force other dialogs to close or just refuse to open a new dialog?

Discussed with pbommana@ offline and we decided to remove the blocker.

Please target a fix for M60.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1799a1223112af65e44eba61dc4feb885389bfe2

commit 1799a1223112af65e44eba61dc4feb885389bfe2
Author: thomasanderson <thomasanderson@chromium.org>
Date: Wed Jun 14 00:02:02 2017

Change linux default hidden file save directory to XDG_DATA_HOME

Versions of GTK3 up to 3.14.7 had a bug that would cause a segfault
when a GtkFileChooser was open and a hidden file in the directory was
deleted [1].

Chrome can trigger this bug in the following scenario:
1. Open 2 windows
2. Open a save dialog in each window
3. Close one of the dialogs

Chrome saves a file in two stages: it writes the contents to a hidden
file, and then renames it to the actual file.  This is so the file can
be downloading as the user is choosing a file to save to.

By default, the hidden file is placed into whichever directory the
save dialog opens with.  In the case of 2 save dialogs open at once,
if the user saves the file (renames the hidden file) or cancels the
download (deletes the hidden file), the GTK bug would be triggered.

This CL changes the default directory for the hidden files to
XDG_DATA_HOME in an effort to make triggering the GTK bug far less
likely.

[1] https://mail.gnome.org/archives/commits-list/2014-December/msg02447.html

BUG= 728501 
R=thestig@chromium.org
TBR=qinmin@chromium.org

Review-Url: https://codereview.chromium.org/2924433002
Cr-Commit-Position: refs/heads/master@{#479213}

[modify] https://crrev.com/1799a1223112af65e44eba61dc4feb885389bfe2/chrome/browser/shell_integration_linux.cc
[modify] https://crrev.com/1799a1223112af65e44eba61dc4feb885389bfe2/chrome/browser/shell_integration_linux.h
[modify] https://crrev.com/1799a1223112af65e44eba61dc4feb885389bfe2/content/browser/download/download_manager_impl.cc
[modify] https://crrev.com/1799a1223112af65e44eba61dc4feb885389bfe2/content/browser/download/download_manager_impl_unittest.cc

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Since this is a regression, Approving merge for M60. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/686705b6198717779f1452d0fda7d50245eb0d0f

commit 686705b6198717779f1452d0fda7d50245eb0d0f
Author: thomasanderson <thomasanderson@chromium.org>
Date: Fri Jun 16 23:35:42 2017

[Merge to M60] Change linux default hidden file save directory to XDG_DATA_HOME

> Versions of GTK3 up to 3.14.7 had a bug that would cause a segfault
> when a GtkFileChooser was open and a hidden file in the directory was
> deleted [1].
>
> Chrome can trigger this bug in the following scenario:
> 1. Open 2 windows
> 2. Open a save dialog in each window
> 3. Close one of the dialogs
>
> Chrome saves a file in two stages: it writes the contents to a hidden
> file, and then renames it to the actual file.  This is so the file can
> be downloading as the user is choosing a file to save to.
>
> By default, the hidden file is placed into whichever directory the
> save dialog opens with.  In the case of 2 save dialogs open at once,
> if the user saves the file (renames the hidden file) or cancels the
> download (deletes the hidden file), the GTK bug would be triggered.
>
> This CL changes the default directory for the hidden files to
> XDG_DATA_HOME in an effort to make triggering the GTK bug far less
> likely.
>
> [1] https://mail.gnome.org/archives/commits-list/2014-December/msg02447.html
>
> BUG= 728501 
> R=thestig@chromium.org
> TBR=qinmin@chromium.org

BUG= 728501 
TBR=qinmin@chromium.org
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true

Review-Url: https://codereview.chromium.org/2948443002
Cr-Commit-Position: refs/branch-heads/3112@{#371}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

[modify] https://crrev.com/686705b6198717779f1452d0fda7d50245eb0d0f/content/browser/download/download_manager_impl.cc
[modify] https://crrev.com/686705b6198717779f1452d0fda7d50245eb0d0f/content/browser/download/download_manager_impl_unittest.cc