Untriaging it so that it gets addressed.

MD settings.

this is probably some nested run loop / constrained window voodoo

Are you sure that's a constrained window, and not a file select dialog/sheet? You should ask Mac folks instead. I'm probably not useful here.

whoops, wrong bug, sorry

either way, they're probably blocking something from continuing to render/animate

The message loop is getting starved, but I don't think there's anything we can do about that. A portion of the relevant sample for opening the sheet per the repro steps:

  385 settings::DownloadsHandler::HandleSelectDownloadLocation(base::ListValue const*)  (in Google Chrome Framework)  load address 0x10a616000 + 0x376b0ae  [downloads_handler.cc:48]
    374 ui::SelectFileDialogImpl::SelectFileImpl(ui::SelectFileDialog::Type, base::string16> const&, NSWindow*, void*)  (in Google Chrome Framework)  load address 0x10a616000 + 0x2e5eb9e  [
    + 349 -[NSSavePanel beginSheetModalForWindow:completionHandler:]  (in AppKit) + 617  [0x7fff8f563387]
    + ! 343 -[NSApplication _commonBeginModalSessionForWindow:relativeToWindow:modalDelegate:didEndSelector:contextInfo:]  (in AppKit) + 1045  [0x7fff8f14c8af]
    + ! : 326 -[NSApplication _orderFrontModalWindow:relativeToWindow:]  (in AppKit) + 270  [0x7fff8f14cd3a]
    + ! : | 326 -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:]  (in AppKit) + 894  [0x7fff8f021f5f]
    + ! : |   318 -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:]  (in AppKit) + 1849  [0x7fff8f0237aa]
    + ! : |   + 317 -[NSWindow(NSSheets) _orderFrontRelativeToWindow:]  (in AppKit) + 200  [0x7fff8f154301]
    + ! : |   + ! 316 -[NSMoveHelper(NSSheets) _moveParent:andOpenSheet:]  (in AppKit) + 1736  [0x7fff8f154a1e]
    + ! : |   + ! : 275 -[NSMoveHelper _doAnimation]  (in AppKit) + 1630  [0x7fff8f1566bc]
    + ! : |   + ! : | 275 CFRunLoopRunSpecific  (in CoreFoundation) + 296  [0x7fff9fde6ed8]
    + ! : |   + ! : |   164 __CFRunLoopRun  (in CoreFoundation) + 1841  [0x7fff9fde7871]

Looking at -[NSMoveHelper _doAnimation], we can see that AppKit is spinning the runloop in a private mode that will starve the CommonModes and DefaultMode, which is why we don't pump tasks to repaint the WebContents.

__text:0000000000247B9A                 mov     rdi, cs:classRef_NSDisplayLink
__text:0000000000247BA1                 mov     rsi, cs:selRef_currentTimestamp
__text:0000000000247BA8                 call    cs:_objc_msgSend_ptr
__text:0000000000247BAE                 mov     r14, cs:_OBJC_IVAR_$_NSMoveHelper__startTime ; double _startTime;
__text:0000000000247BB5                 movsd   qword ptr [rbx+r14], xmm0
__text:0000000000247BBB                 mov     rdi, cs:classRef_NSRunLoop
__text:0000000000247BC2                 mov     rsi, cs:selRef_currentRunLoop
__text:0000000000247BC9                 call    cs:_objc_msgSend_ptr
__text:0000000000247BCF                 mov     rsi, cs:selRef_addToRunLoop_forMode_
__text:0000000000247BD6                 lea     rcx, cfstr__nsmovetimerru ; "_NSMoveTimerRunLoopMode"
__text:0000000000247BDD                 mov     rdi, r15
__text:0000000000247BE0                 mov     rdx, rax
__text:0000000000247BE3                 call    cs:_objc_msgSend_ptr
__text:0000000000247BE9                 mov     [rbp+var_B8], r15
__text:0000000000247BF0                 mov     [rbp+var_AC], r13d
__text:0000000000247BF7                 mov     rax, cs:_OBJC_IVAR_$_NSMoveHelper__done ; char _done;
__text:0000000000247BFE                 cmp     byte ptr [rbx+rax], 0
__text:0000000000247C02                 jnz     short loc_247C80
__text:0000000000247C04                 mov     r12, cs:_OBJC_IVAR_$_NSMoveHelper__totalTime ; double _totalTime;
__text:0000000000247C0B                 mov     r15, cs:selRef_currentTimestamp
__text:0000000000247C12                 lea     r13, cfstr__nsmovetimerru ; "_NSMoveTimerRunLoopMode"
__text:0000000000247C19
__text:0000000000247C19 loc_247C19:                             ; CODE XREF: -[NSMoveHelper _doAnimation]+692j
__text:0000000000247C19                                         ; -[NSMoveHelper _doAnimation]+6B0j
__text:0000000000247C19                 movsd   xmm0, qword ptr [rbx+r12]
__text:0000000000247C1F                 mov     esi, 1
__text:0000000000247C24                 mov     rdi, r13
__text:0000000000247C27                 call    _CFRunLoopRunInMode
__text:0000000000247C2C                 mov     rdi, cs:classRef_NSDisplayLink
__text:0000000000247C33                 mov     rsi, r15
__text:0000000000247C36                 call    cs:_objc_msgSend_ptr
__text:0000000000247C3C                 subsd   xmm0, qword ptr [rbx+r14]

yeah, this is what I figured.  thanks for the detailed analysis, rsesek (completely with fancy ascii art stacks!).

i don't see this as being a particularly big deal.  i'm just going to wontfix.

I'm going to at leave it as a hotlist polish bug - it doesn't stop the software from working, but it doesn't look good either.

I assume dbeam@ that the Change button triggers the dropdown of the open/save panel and simultaneously starts the ripple effect - would it be the end of the world to trigger the dropdown once the ripple effect has completed?

If I can get the ripple effect removed from web-ui MD in the Harmony revision, that would also address this problem.

btw, this CL is probably relevant
https://codereview.chromium.org/2769593002

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Mac triage: marking fixed per #15.