- If there are any crashes listed in chrome://crashes from when this happened, could you share the server IDs?
- If any interesting log messages appear in Console.app at the time of the crash, or crash reports from processes other than Chrome (under User Reports or System Reports — maybe WindowServer?), could you share them?

Does anyone of the chrome-mac team have one of these usb3 display link thingos? This is likely the same problem as  Issue 548824  (that one, for the extension install dialog).

There's a proposal for a tweak to the animation - Issue 682044 - there's a slim chance that the adjustment proposed there manages to avoid this driver bug.

If we can reliably detect this hardware, a workaround could be to just fade-in these dialogs rather than try to morph them. This is the |useSimpleAnimations_| codepaths in https://codereview.chromium.org/1787553003/

Full control over window animations with sufficient performance and stability likely isn't possible without MacAura - macOS doesn't expose APIs that would allow us to do this.

Ideally Apple fix their window server crash, but it's (probably) a private API call that causing the crash, so I don't expect a fix to be forthcoming.

Displaylink have a known-issues page for macOS 10.12 Sierra - http://support.displaylink.com/knowledgebase/articles/949426

It includes
 "The window server can crash logging our [sic] the user when minimising applications, for example iTunes (23182216)"

Which is essentially the problem here. i.e. Some window animation crashing the WindowServer process.

There are no crash reports available. Console.app doesn't seem to have anything interesting.

Also I reported this to the DisplayLink guys and I wait for inputs from their side.

Thank you for providing more feedback. Adding requester "sdy@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I updated DisplayLink on my macOS to the latest version but the behaviour persists. So I think it would be helpful for other users if Chrome would use another method for the cookie window. I am also in contact with DisplayLink but they seem to have no solution for that (at least not at the moment).

[mac triage] I don't have any ideas for a fix, but this shouldn't be in triage.

I updated DisplayLink to their 4.0 beta driver and the crash happens one step later when trying to close the cookie window. But still the same.

Also I read about:
"If we can reliably detect this hardware, a workaround could be to just fade-in these dialogs rather than try to morph them. This is the |useSimpleAnimations_| codepaths in https://codereview.chromium.org/1787553003/"

Couldn't this be a possible fix?

If we know how to detect the hardware we can probably choose the fallback path. Could you run this in Terminal:

ioreg > ~/Desktop/ioreg-755516.txt

That will put a text file on your desktop. You can then email me the results directly (it contains some unique serial numbers for your hardware, so you may not want to attach that directly to the bug). That will allow us to know which hardware class to probe for.

I will send it to your mail address.

I think the public information (and maybe relevant for other devs) is this:
    | |   |   |   | | +-o Displaylink USB3.0 dock@14620000  <class IOUSBHostDevice, id 0x100001beb, registered, matched, active, busy 0 (7459 ms), retain 48>
      +-o DisplayLinkVirtualDevice  <class DisplayLinkVirtualDevice, id 0x100000126, !registered, !matched, active, busy 0 (66 ms), retain 9>
      | +-o DisplayLinkParent0@0  <class DisplayLinkParent, id 0x100000139, registered, matched, active, busy 0 (52 ms), retain 7>
      | | +-o DisplayLinkFramebuffer@0  <class DisplayLinkFramebuffer, id 0x10000013a, registered, matched, active, busy 0 (51 ms), retain 13>
      | +-o DisplayLinkParent1@1  <class DisplayLinkParent, id 0x100000278, registered, matched, active, busy 0 (57 ms), retain 10>
      | | +-o DisplayLinkFramebuffer@1  <class DisplayLinkFramebuffer, id 0x100000279, registered, matched, active, busy 0 (53 ms), retain 16>
      | | +-o DisplayLinkUserClient  <class DisplayLinkUserClient, id 0x100001d70, !registered, !matched, active, busy 0, retain 5>
      | | +-o DisplayLinkUserClient  <class DisplayLinkUserClient, id 0x100001d71, !registered, !matched, active, busy 0, retain 5>
      | | +-o DisplayLinkUserClient  <class DisplayLinkUserClient, id 0x100001e7e, !registered, !matched, active, busy 0, retain 5>
      | +-o DisplayLinkParent2@2  <class DisplayLinkParent, id 0x100000288, registered, matched, active, busy 0 (60 ms), retain 7>
      | | +-o DisplayLinkFramebuffer@2  <class DisplayLinkFramebuffer, id 0x100000289, registered, matched, active, busy 0 (60 ms), retain 13>
      | +-o DisplayLinkParent3@3  <class DisplayLinkParent, id 0x1000002a5, registered, matched, active, busy 0 (59 ms), retain 7>
      | | +-o DisplayLinkFramebuffer@3  <class DisplayLinkFramebuffer, id 0x1000002a6, registered, matched, active, busy 0 (58 ms), retain 13>
      | +-o DisplayLinkAccelerator  <class DisplayLinkAccelerator, id 0x1000002d2, registered, matched, active, busy 0 (0 ms), retain 32>
      | |   +-o Displaylink USB3.0 dock@14620000  <class AppleUSBDevice, id 0x100001bee, registered, matched, active, busy 0 (2441 ms), retain 34>
      | |   | +-o DisplayLinkManag  <class IOUSBDeviceUserClientV2, id 0x100001bf3, !registered, !matched, active, busy 0, retain 5>
      | |   | | +-o DisplayLinkManag  <class IOUSBInterfaceUserClientV3, id 0x100001d5b, !registered, !matched, active, busy 0, retain 7>

Thanks -- that's very helpful. I've got a CL to use simple animations if we detect the DisplayLinkFramebuffer IOService. https://chromium-review.googlesource.com/c/chromium/src/+/700424

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

commit 7827a538ddbfacaa0558195ae2dabb6aa556a117
Author: Robert Sesek <rsesek@chromium.org>
Date: Thu Oct 05 15:46:03 2017

[Mac] Use simple ConstrainedWindow animations if DisplayLink is detected.

The private window animation APIs used by ConstrainedWindow tend to crash
the WindowServer when DisplayLink hardware is attached. This change enables
the use of the simple animation style when the DisplayLinkFramebuffer is
found in the IOKit registry.

Bug:  755516 
Change-Id: Iae2faa92bb987973f6e94bb3e1ed0d13f3ce3579
Reviewed-on: https://chromium-review.googlesource.com/700424
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#506740}
[modify] https://crrev.com/7827a538ddbfacaa0558195ae2dabb6aa556a117/chrome/browser/ui/cocoa/constrained_window/constrained_window_custom_sheet.h
[modify] https://crrev.com/7827a538ddbfacaa0558195ae2dabb6aa556a117/chrome/browser/ui/cocoa/constrained_window/constrained_window_custom_sheet.mm

OP: The fix should be in tomorrow's canary build. Could you give that a try tomorrow and see if the issue is resolved?